[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [higgins-dev] STS profile problems
|
Once the Context is open, you can do getSubject on many different
subjects. You're not limited to dealing with that subject (if any) that
is associated with the credentials used to open the Context.
I do not disagree to have some "default" DigitalSubject. But I disagee to
get claim values from this default Subject as it gets now in
DigitalIdentityHandler. At least because IContext.open() can return null
(according to the current docs).
Thanks,
Sergey Lyakhov
----- Original Message -----
From: "Greg Byrd" <gbyrd@xxxxxxxx>
To: "Higgins (Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
Sent: Friday, July 27, 2007 3:16 PM
Subject: Re: [higgins-dev] STS profile problems
Once the Context is open, you can do getSubject on many different
subjects. You're not limited to dealing with that subject (if any) that
is associated with the credentials used to open the Context.
...Greg
Sergey Lyakhov wrote:
> 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 -----
*From:* Daniel Sanders <mailto:dsanders@xxxxxxxxxx>
*To:* Higgins (Trust Framework) Project developer discussions
<mailto:higgins-dev@xxxxxxxxxxx>
*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:
http://www.bandit-project.org/index.php/Security_Token_Service_Download
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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev