[higgins-dev] Re: STS profile problems

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

As Daniel pointed out, this message is built upon some incorrect information.  Let's make sure we straighten out any misconceptions about the way things are today, before proposing fixes to them.
 
> the peculiarity of JNDI CP - each context contains single digital subject

This is neither peculiar to the JNDI CP, nor is it true of any deployment of the JNDI CP that I have ever seen.  Let me explain what I just said:  Any deployment of any CP might allow a context to contain a single digital subject.  The JNDI CP is no different.  However, the JNDI CP also allows any number of digital subjects to exist in contexts it produces, and in fact, all the deployments I have seen of the JNDI CP to date do have multiple digital subjects in the contexts they produce.

The generic consumer of IdAS should be able to work in situations where there are one or many subjects in a context.  The STS *happens* to only care about one subject (per RST) today (the one which is represented in the credentials passed to it).  However, as the STS uses (or can use) the same context to service many RST's over time (each of which might be request for security tokens for different individuals), then such a context must be comprised of multiple digital subjects.

> and subject ID is returned by IContext.open() method

This also is not peculiar to the JNDI CP.  The current IdAS documentation states that this is the ID of the subject which was used to open the context, and that it may be null.  A generic consumer of IdAS should be able to work in situations here this value is null.  What does this mean for the STS?  It means that in the case where the STS expected there to be a value (one case being when a username/password was passed in the credential to the STS), and this value is null, the STS should have a failover strategy.  This strategy could be one where the STS uses data which was passed in the credential (the username for example) in order to determine the contextID.


 

>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 7/25/07 2:06 PM >>>
Hello,

We need to be able to use any implementation of IdAS context to manage STS 
user profile. We are going to implement a new user profile plugin (like 
org.eclipse.higgins.sts.server.profile) which will use any implementation of 
IdAS context and perform all operations (including profile creation) using 
IdAS methods (now LDAP is directly used to create/modify a profile). 
However, we have the following problems with DigitalIdentityHandler:

1. DigitalIdentityHandler is implemented to use the peculiarity of JNDI CP - 
each context contains single digital subject and subject ID is returned by 
IContext.open() method. I think we should not use this peculiarity anywhere. 
Moreower, I think IContext.open()  should return nothing (void). Perhaps, in 
case of JNDI CP it will be more convinient to alwauys return its single 
subject for any value of passed subjectID. In other words, JNDI 
IContext.getSubject(String subjectID) should always return the same subject 
for any passed  subjectID, even for null.

2. To find appropriate DigitalSubject, we need its subjectID. So, CardID 
should contain both contextRef and subjectID (subjectID will be missed for 
JNDI provider).

3. In case of SelfSigned cards, cardID should also contain contextRef + 
subjectID (now it contains IssuerID of selfIssued cards).

4.  Perhaps, STS should not use DefaultContextRef. It should be a problem of 
IdASRegistry to initialize any ContextFactory and find required context.

Thanks,
Sergey Lyakhov