Skip to main content

[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.

...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



Back to the top