Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] STS profile problems

> When you log in to that web page, for informational reasons, it displays your userID at the top of the page. 
> Or maybe your name is bold or underlined in the list.  This is to show you that it is you who has logged in. 
> Now, at the same time, you can view all the other members of the list. 
> This is like opening a context, and being able to see subjects.
 
So, when I logged in with my credentials, I can see the claim values of cards of other people?
 
> IContext.open returns the name of the person who logged in.  This makes it easy to determine who logged in.
> This may be used for informational purposes or other purposes.
 
I do not have any objections. However, this type of DigitalSubject is not standardized and there can be some problems to use different CPs. Perhaps, we need to add such type of DigitalSubject to higgins.owl schema and IContext.open() should allways return its instance for all CPs. But now the DigitalSubject obtained by this subjectID is used by DigitalIdentityHandler to store claim values of card. What should we do if IContext.open() method of some CP does not return such subjectID?
 
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Friday, July 27, 2007 6:07 PM
Subject: Re: [higgins-dev] STS profile problems

Let's try an analogy.
 
Pretend we had a webpage that contained a list of Higgins committers.  Now pretend that any member of that list could log in to that web page and view that list.  When you log in to that web page, for informational reasons, it displays your userID at the top of the page.  Or maybe your name is bold or underlined in the list.  This is to show you that it is you who has logged in.  Now, at the same time, you can view all the other members of the list.  This is like opening a context, and being able to see subjects.
 
IContext.open returns the name of the person who logged in.  This makes it easy to determine who logged in. This may be used for informational purposes or other purposes.  The person who logs in (calls open) can also see other subjects in the context, analogous to the pretend scenario above. 
There are good reasons to have open return the identity of the subject that called open (authenticated).  In some cases, the authentication materials cannot be used by the caller to determine the identity of the subject represented by those materials, but the CP is able to do this.
 
Jim

>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 7/27/07 6:06 AM >>>
> Where did the idea that a JNDI context provider only has one digital subject come from? That is not the case.
 
I ment - has one digital subject per OPEN instance of context (we can not get subject from non-open context).
 
 
> The subject ID returned by open is simply the subject ID of the digital subject whose credentials were passed in.
 
Is it correct to link the user credentials with the subjectID one-to-one? Why, in that case, do we need to pass the subject ID to IContext.getSubject() method? Why do we need getSubjects() method if open Context can return only one DigitalSubject? According to the documentation of IContext.open() method, we can not operate with non-open Context (invoke methods addSubject(), getSubject(), getSubjects() etc.). Current IContext interface assumes to be able to store more then one DigitalSubject instance per user (credentials). So, that is why I think IContext.open() should not return the subjectID and ICard (its cardID) should contain ID of DigitalSubject.
 
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Thursday, July 26, 2007 6:10 PM
Subject: Re: [higgins-dev] STS profile problems

Where did the idea that a JNDI context provider only has one digital subject come from?  That is not the case.  Once a context is open, there are methods for obtaining/creating any number of digital subjects - getSubject, addSubject.  The subject ID returned by open is simply the subject ID of the digital subject whose credentials were passed in.  There is no presumption that this is the one and only digital subject that has to be retrieved or even will be retrieved.
 
As to information cards containing the subject ID, remember that there is already a user credential specified in the card.  The user credential is what is passed to the STS to identify the digital subject whose claims are to be retrieved.  When the user credential type is username/password, it is possible to actually use a single card to retrieve claims for many digital subjects.  I would recommend that subject ID NOT be part of the card ID (if that is what is being proposed here - it's not clear to me what is being proposed).
 
I have created an entire IdP using IdAS (see http://wag.bandit-project.org).  It is a servlet coded in JSP and deployed on Tomcat.  It is capable of creating users (profiles), maintaining user profiles, issuing managed cards, and issuing security tokens.  It incorporates the higgins STS for issuing security tokens.  It happens to use the JNDI context provider, but is not limited to it.  It has been built using IdAS functionality to keep it independent.  The context provider is configurable, as are many other things.  There is a web interface for configuring and administering it (the admin URL is http://wag.bandit-project.org/TokenService/admin.jsp).  If you would like, you can take a look at the code by downloading the tarball at the following location:
 
 
The sts-1.0.654.tar.gz file contains all of the source.  Look in the *.jsp files to see how I use IdAS.  We have built this open source solution in the hopes that it would be helpful to others who want to create an IdP that uses Higgins components.
 
Daniel

>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 7/26/2007 7:01 AM >>>
Paul,

> Why do you think this is bad/peculiar?

According to IContext interface, IContext.open() method can return ID of
DigitalSubject.  It assumes, that each instance of IContext contains exactly
one DigitalSubject (or some default subject). But I think this is special
case of JNDI provider (one DigitalSubject per Context), and we should not
accept this rule for all CPs. Context should be able to contain more then
one DigitalSubject. So, I propose:

1. Change the result type of IContext.open() from String to void.

2. If we need to get some DigitalSubject from the Context we MUST have
subjectID of required Subject. In other words, if  we need to get
DigitalSubject with claim values of some card, this card should contain both
contextID and subjectID.

In case of JNDI CP, empty string can be used as subjectID because this CP
always contain one DigitalSubject per Context. In any case we need standard
way to get DigitalSubject from Context.

Thanks,
Sergey Lyakhov

----- Original Message -----
From: "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
To: "'Higgins (Trust Framework) Project developer discussions'"
<higgins-dev@xxxxxxxxxxx>
Sent: Thursday, July 26, 2007 12:12 AM
Subject: RE: [higgins-dev] STS profile problems


> Sergey wrote:
> ...
>> 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. Moreover, I think IContext.open() should return nothing (void).
>
> Why do you think this is bad/peculiar?
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev


_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Back to the top