[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [higgins-dev] Re: Redirecting Bandit STS efforts to Higgins
|
The provider generates (and potenially cancels, validates) the outbound
token - regardless of inbound credential token. So far we have always only
used the SAML provider.
higgins-dev-bounces@xxxxxxxxxxx wrote on 02/23/2007 06:48:52 PM:
> I guess this is where I would like a better understanding of the
> internal STS architecture. When you say "SAML provider", I assumed
> you were referring to an "outgoing" security token type that goes
> out in the RSTS (SAML vs. Kerberos vs. something else), as opposed
> to an "incoming" credential type that comes in the RST (SAML,
> username/password, etc.). There are two extension projects:
>
> org.eclipse.higgins.sts.extensions.samltoken
> org.eclipse.higgins.sts.extensions.usernametoken
>
> that would seem to me to refer to incoming credential types that
> come in the RST, not outgoing RSTS token types. I guess I am basing
> this on my understanding that there is an outgoing SAML token type,
> but not an outgoing usernamepassword token type - I'm not sure what
> that would mean. Hence, I assumed these projects primarily referred
> to different handlers for the kinds of credentials that can come in the
RST.
>
> However, I can see in the samltoken project, in the "...
> /SAMLToken/IssueHandler.java" source file, that you handle both
> username/password and self-issued SAML credentials. That leaves me
> wondering what the purpose of the usernametoken project is. Is it
> now no longer needed? or is it a placeholder for future work? --
> Sorry to be so dumb about this ... just trying to get a better
> understanding of the internal architecture of the STS... I would
> appreciate any clarification you can give me.
>
> Thanks,
>
> Daniel
>
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/23/2007 2:40 PM >>>
> The SAML Provider is the only implemented provider that gets claims from
> IdAS right now. Eventually other providers will need to do the same
thing.
> That is why I'd architected it the way it was before (framework gets the
> DigitalSubject without specifying specific claims - then specifying all
> known claims when that stopped working - now framework does not get the
> DigitalSubject, then provider does).
>
>
>
>
> "Daniel Sanders" <dsanders@xxxxxxxxxx> wrote on 02/23/2007 10:38:22 AM:
>
> > Thanks Mike. -- I did have a followup question on #2 (PPID claim
> > handling). This should be independent of SAML provider, so I'm not
> > sure what you mean here. All providers should do it this way,
> > should they not? Am I misunderstanding what you mean by SAML
> > provider? Could you clarify this?
> >
> > I am also putting this particular e-mail out on the dev list - minus
> > the other discussion about contributing to the STS.
> >
> > Thanks,
> >
> > Daniel
> >
> > >>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/23/2007 8:22 AM >>>
> > "Daniel Sanders" <dsanders@xxxxxxxxxx> wrote on 02/22/2007 03:45:49
PM:
> >
> > > The term "fully implemented" implies a lot more than you are
> > > allowing for. It includes major and minor bug fixes, reliability
> > > fixes, scalability fixes, etc., etc. It's stuff that benefits ALL
> > > users of the STS. There is a lot of stuff in the STS that people
> > > are VERY interested in, that ought to be in the STS, that is not
> > > going to be specified in a high-level WS-Trust document. We need to
> > > collaborate about these things, including submitting patches and/or
> > > committing changes, bug fixes, etc. directly. We would like to be
> > > able to help with these things. We would like a task list or to-do
> > > list that everyone can help out with - as is common with most other
> > > open source projects.
> > >
> > > Examples of things that have recently been requested are as follows:
> > >
> > > 1) Some restructuring of the code modules. See my e-mail, and
> > > Mike's response - both out on the higgins-dev list if you are
watching
>
> > it:
> > > http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01607.html
> >
> > Allow 1 STS Core to be used by N STS Bindings - this is checked in
today
>
> > (you can now pass a configured STS instance into the binding configure
> > method and get the configured STS instance from a binding).
> >
> > > 2) A change in how PPID claims are handled. See http://wiki.
> > > eclipse.org/index.php/Milestone_0.7 under the heading "IIW Reference
> > > Application Post Mortem"
> >
> > PPID handling - this has been how the SAML provider works since the
F2F.
> >
> > > 1. The STS needs to give special handling to the
> > > privatepersonalidentifier claim. The document, A Guide to
> > > Integrating with Information Cards and Windows CardSpace v1.0, says
> > > the following: "To enable an identity provider that supports the
> > > PPID claim type to be able to always produce a consistent claim
> > > value, Windows CardSpace includes the extension element ic:
> > > ClientPseudonym/ic:PPID in the RST request. It contains the result
> > > of applying a hash function to a relying party identity and optional
> > > user-supplied entropy to produce an opaque yet consistent reference
> > > for the relying party. If the issued token contains the PPID claim,
> > > this value is to be used as the basis. The IP/STS may use this value
> > > as is or as an input seed to a custom function to derive a value for
> > > the PPID claim." The STS should look for this ClientPseudonym/PPID
> > > element whenever the RST requests the personalprivateidentifier
> > > claim, and at the very least, return that value for the claim.
> > > 3) A change in how the STS determines what claims to ask for from
> IdAS.
> > See:
> > > http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01541.html.
> >
> > Ask for specific claims when calling getDigitalSubject - this is
checked
>
> > in today (I still feel that this is an LDAPism and would like to
discuss
>
> > whether getDigitalSubject is expected to provide dynamic read-write
> access
> > via an to the DigitalSubject or whether its expected to provide a
static
>
> > cached copy of the Digital Subject.
> > >
> > > Mike may have already worked on some of these, perhaps all of them.
> > > I haven't checked for the past few days. I am just showing you that
> > > there are things that need tweeking, adjusting, refactoring, etc. -
> > > that have little or nothing to do with the high-level WS-Trust
> > > architecture. These kinds of requests come up somewhat regularly,
> > > and we anticipate that more will happen.
> >
> > I also am waiting for the change to the IdAS described here:
> > http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg01601.html
> >
> > > Daniel Sanders
> >
> > <snip rest of
discussion...>_______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev