| [higgins-dev] Re: Redirecting Bandit STS efforts to Higgins |
|
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...> |