[higgins-dev] Re: Bandit-free sample IdAS consumer code

[Greg Byrd <gbyrd@xxxxxxxx>]

You (the application programmer) don't have to read in or instantiate the factory classes if this is done via configuration.  And contexts do not need to be registered.  So you could start with a contextRef, instantiate a registry (which creates factories automatically), and then use the registry to find a suitable factory for your contextRef.

I know nothing about Tomcat or its config file.  So now we have three different proposals for configuration -- clearly something to discuss later this week.

As for the register method -- also a topic of discussion.  After Tony and Valery discussed the merits of requiring permission to add a new factory, I realized that the IdASRegistry.registerContext method skips that protection entirely.  So I think we need discussion of the bigger security picture before settling on this one.

...Greg


Jim Sermersheim wrote:

Greg Byrd <gbyrd@xxxxxxxx> 11/13/06 3:44 PM >>>
        

You're passing a string (prop) to registerContextFactory, rather than an 
IContextFactory (line 55).   I suppose we could add that to the API, but 
it's currently not there.  You need to create an object first with 
newInstance().
    

In my haste, I forgot to mention that I added that method.  We can remove it if in the end it seems useless.  I also prefixed local member variables with an underscore to make the file more readable to me (sorry if this bugs you, I can change back if you want).
 
  

You could make this happen automatically when the IdASRegistry is 
created by: 
(1) creating a Provider class, 
(2) setting the "ContextFactory.FOO" property to the class name, and 
(3) adding the 
provider class name to the java.security file.  See the JUnit test code 
for an example of a Provider class.  (In the tests, the provider is add 
dynamically via Security.addProvider, rather than via the file.)
    

Yeah, I was thinking of going that route, but wanted to be lazy and cut/paste from an example :)

Actually that's a lie.  What I was hoping for is to be pointed at a Tomcat config file wherin I could specify the required elements of a Provider.Service and have Tomcat add that to its own Provider (assuming it has one).  I haven't yet seen anything like that yet.

I mean, if ultimately I have to read a) the names of the factories, and b) the contextRefs, and if I have to instantiate the factories and add them to the registry. What does the registry buy me?  I think it just makes it so I don't have to call each factory I know about and call canCreate.

  

The "FOO" is the "algorithm" name for the factory.  Right now, this is 
meaningless, but it is used to distinguish between different context 
factory classes.  It can be anything you want, as long as it's different 
for each ContextFactory listed in a given Provider.  Maybe later we can 
standardize on some labels and their meanings.

Registering the contextRef looks fine to me.
    

I realized later that I actually don't need to register the contextRef because getContextFactories(contextRef) doesn't need them to be registered (doesn't make use of _registeredContextMap)





Jim Sermersheim wrote:
  

<resending again, and cc'ing people who might care.  I don't know why 
these fail to hit the list>
 
<resent -- sorry if this is a duplicate>
 
Attached.
 
Greg, I used the IdASRegistry in a way that I'm sure is not at all 
intended because effectively all I did was put stuff into a bag and 
take it back out (see lines 53 through 72).  Can you give us a brief 
overview or sample of how it's intended to be used (it would be nice 
if there was an integration with some Tomcat security provider, but we 
couldn't figure out what to do there)
 
I'll start seeing how this should fit into the STS code next (now that 
it's completely Bandit free)
 
Jim