LoginHandler Mapping/Flow

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

LoginHandler Mapping/Flow

Paul Hethmon
LoginHandler Mapping/Flow Ok, so based on some questions Peter has been asking me as we get his Ping SP talking to my Shib IdP based system, I’m looking for a better understanding of how Shib goes from the LoginHandler configuration in handler.xml to actual code and methods used.

So, in the <LoginHandler> element, we have xsi:type attribute with allowable values of RemoteUser, UsernamePassword, and PreviousSession only. Then we have the <AuthenticationMethod> specified per SAML2 authentication context types. That seems pretty straightforward.

The part I haven’t found yet is where the link from that config to the actual servlet code handling the different types of authentication. The only thing I really see is that the servlet names in web.xml follow a pattern to the attribute values. Then there are the *Handler classes in “edu.internet2.middleware.shibboleth.idp.authn.provider”. So it appears that the handler.xml config causes the appropriate handler class to then load the appropriate servlet class to handle the requested authentication context type.

In my usage, I’m actually replacing the UsernamePasswordLoginServlet class with my own to implement two factor authentication and that is working well. Shib redirects to my servlet and accepts the results just fine. I just want to make sure I understand the flow.

Thanks,

Paul


-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

Give a man a fire and he's warm for the day. But set fire to him and he's warm for the rest of his life.

 -- Terry Pratchett, Discworld

Reply | Threaded
Open this post in threaded view
|

Re: LoginHandler Mapping/Flow

Paul Hethmon
Re: [Shib-Users] LoginHandler Mapping/Flow A follow up question on this. SAML spec gives quite a few authentication context types to choose from, but not one for an event-drive token device (only time sync). So, can I create my own? It looks like Shib itself won’t support it without code changes, but it seems possible to insert a new type following the framework in the IdP. I guess part two of that is whether SAML2 allows you to do that?

Thanks,

Paul


On 1/22/09 11:58 AM, "Paul Hethmon" <paul.hethmon@...> wrote:

Ok, so based on some questions Peter has been asking me as we get his Ping SP talking to my Shib IdP based system, I’m looking for a better understanding of how Shib goes from the LoginHandler configuration in handler.xml to actual code and methods used.

So, in the <LoginHandler> element, we have xsi:type attribute with allowable values of RemoteUser, UsernamePassword, and PreviousSession only. Then we have the <AuthenticationMethod> specified per SAML2 authentication context types. That seems pretty straightforward.

The part I haven’t found yet is where the link from that config to the actual servlet code handling the different types of authentication. The only thing I really see is that the servlet names in web.xml follow a pattern to the attribute values. Then there are the *Handler classes in “edu.internet2.middleware.shibboleth.idp.authn.provider”. So it appears that the handler.xml config causes the appropriate handler class to then load the appropriate servlet class to handle the requested authentication context type.

In my usage, I’m actually replacing the UsernamePasswordLoginServlet class with my own to implement two factor authentication and that is working well. Shib redirects to my servlet and accepts the results just fine. I just want to make sure I understand the flow.

Thanks,

Paul


-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

Give a man a fire and he's warm for the day. But set fire to him and he's warm for the rest of his life.

 -- Terry Pratchett, Discworld





-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

Give a man a fire and he's warm for the day. But set fire to him and he's warm for the rest of his life.

 -- Terry Pratchett, Discworld

Reply | Threaded
Open this post in threaded view
|

RE: LoginHandler Mapping/Flow

Cantor, Scott E.
Paul Hethmon wrote on 2009-01-22:
> A follow up question on this. SAML spec gives quite a few authentication
> context types to choose from, but not one for an event-drive token device
> (only time sync). So, can I create my own? It looks like Shib itself won't
> support it without code changes, but it seems possible to insert a new
type
> following the framework in the IdP. I guess part two of that is whether
> SAML2 allows you to do that?

The IdP doesn't know anything about the classes or what they mean. There's
no code to write just to make up a class.

As for whether you "can", you can do anything you want. Think long and hard
about who's going to accept the value, what it will mean, what they plan to
do with it, and how you'll version/evolve it.

e.g. What if you want to tweak the class definition and change to a new URI?
Does the SP now have to change to deal with that? Lots of people think
that's unacceptable.

My advice? Pick a class that's close and just live with it. Does the SP
really care what kind of two-factor token was used?

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: LoginHandler Mapping/Flow

peter williams-3
In reply to this post by Paul Hethmon
LoginHandler Mapping/Flow

 

1.     I think I also want the IDP to react to a requested format of urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted, only encrypting the nameid type when requested (rather than all the time).Can Shib IDP do this?

 

2.     If we make ShibIDP pull SP metadata upon getting a req event, I can dynamically alter the SP’s  X509SKI that points to a collection of certificates in the SPSSO metadata’s first and only X509Data. IN that way, given the “algorithm” Shib IDP uses, the SP can control which public key the IDP will use and which ciphers/keylengths/… will be used (when it knows its talking to Shib IDP).

 

3.     If I combine 1. and 2.  with SPNameQualifier in the request, asking the nameid value from the IDP to be that attached to a nominated SP (which is specifically not the requesting SP), can Shib IDP be configured to supply a particular user attributes as that value? This would give me authoritative IDP-side account linking, from saml name auth à user’s openid URL, say.

 

From: Paul Hethmon [mailto:[hidden email]]
Sent: Thursday, January 22, 2009 8:58 AM
To: Shibboleth Users
Subject: [Shib-Users] LoginHandler Mapping/Flow

 

Ok, so based on some questions Peter has been asking me as we get his Ping SP talking to my Shib IdP based system, I’m looking for a better understanding of how Shib goes from the LoginHandler configuration in handler.xml to actual code and methods used.

So, in the <LoginHandler> element, we have xsi:type attribute with allowable values of RemoteUser, UsernamePassword, and PreviousSession only. Then we have the <AuthenticationMethod> specified per SAML2 authentication context types. That seems pretty straightforward.

The part I haven’t found yet is where the link from that config to the actual servlet code handling the different types of authentication. The only thing I really see is that the servlet names in web.xml follow a pattern to the attribute values. Then there are the *Handler classes in “edu.internet2.middleware.shibboleth.idp.authn.provider”. So it appears that the handler.xml config causes the appropriate handler class to then load the appropriate servlet class to handle the requested authentication context type.

In my usage, I’m actually replacing the UsernamePasswordLoginServlet class with my own to implement two factor authentication and that is working well. Shib redirects to my servlet and accepts the results just fine. I just want to make sure I understand the flow.

Thanks,

Paul


-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

Give a man a fire and he's warm for the day. But set fire to him and he's warm for the rest of his life.

 -- Terry Pratchett, Discworld

Reply | Threaded
Open this post in threaded view
|

Re: LoginHandler Mapping/Flow

Brent Putman
In reply to this post by Paul Hethmon


Paul Hethmon wrote:
LoginHandler Mapping/Flow
The part I haven’t found yet is where the link from that config to the actual servlet code handling the different types of authentication. The only thing I really see is that the servlet names in web.xml follow a pattern to the attribute values. Then there are the *Handler classes in “edu.internet2.middleware.shibboleth.idp.authn.provider”. So it appears that the handler.xml config causes the appropriate handler class to then load the appropriate servlet class to handle the requested authentication context type.

It's actually pretty simple.  The UsernamePassword and RemoteUser LoginHandlers have a configuration property which specifies the endpoint of the associated servlet to which they redirect.  In the wiki doc pages for those 2, see the optional config parameters "authenticationServletURL" and "protectedServletPath, respectively.  The defaults are documented there (which should match what you see in the web.xml).




In my usage, I’m actually replacing the UsernamePasswordLoginServlet class with my own to implement two factor authentication and that is working well. Shib redirects to my servlet and accepts the results just fine. I just want to make sure I understand the flow.

That's how the UsernamePassword handler works, yes.


Note however that the fact that these two LoginHandlers use a separate associated servlet, and redirect to it as a part of the authentication process, is entirely an implementation detail of those LoginHandlers.  The RemoteUser one does it because you need to be able to protect a distinct endpoint with your web server or container, rather than the entire IdP context.  The UsernamePassword one does it because it needs to throw up a form, collect creds from the user, and have some place to post those - and it chooses to do that with a servlet endpoint.

A LoginHandler can in general do whatever it wants, e.g. use (possibly multiple) redirection(s) or not; use a servlet or not, etc. 

As to the exact flow, I'll take a stab at documenting this in the Wiki (after I clarify something with Chad about public API), but it's essentially:


1) ProfileHandler determines that authN is necessary and does a servlet API RequestDispatcher#forward to the AuthenticationEngine servlet.

2) AuthenticationEngine servlet selects a LoginHandler, taking into account various things like:  requested and supported AuthenticationMethods; isPassive and forceAuthn; and presence of a previously established IdP Session.  It also does some setup and/or housekeeping of LoginContext and Session.

3) The selected handler's LoginHandler#login(request,response) is invoked.

4) LoginHandler does whatever it wants to do to authenticate the user, e.g redirect to another endpoint (servlet or jsp) to collect credentials, or validate inline credentials directly, etc.

5) The currently running component (e.g.  either the LoginHandler itself or an associated servlet) calls the static method AuthenticationEngine.returnToAuthenticationEngine(request, response), which in turn essentially just does a RequestDispatcher#forward to the AuthenticationEngine servlet.

6) AuthenticationEngine servlet does some LoginContext and Session housekeeping, and then does a RequestDispatcher#forward back to the originating profile handler URL (where the Shib ProfileRequestDispatcher servlet then dispatches to the associated ProfileHandler).

--Brent


Reply | Threaded
Open this post in threaded view
|

Re: RE: LoginHandler Mapping/Flow

Brent Putman
In reply to this post by peter williams-3


Peter Williams wrote:
LoginHandler Mapping/Flow

 

1.     I think I also want the IDP to react to a requested format of urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted, only encrypting the nameid type when requested (rather than all the time).Can Shib IDP do this?


Yes, it does respect that format for NameIDPolicy.  However, if you only want encryption when requested, and assuming front-channel bindings (which never support confidentiality by definition), you'd have to (rather counter-intuitively) set encryptNameIds="never" rather than the default of "conditional" on the relevant RelyingParty/ProfileConfiguration. 

Arguably we should should perhaps add an additional value for encryptNameIds like "request" or something, to make that a little more sensible to the average human.

 

2.     If we make ShibIDP pull SP metadata upon getting a req event, I can dynamically alter the SP’s  X509SKI that points to a collection of certificates in the SPSSO metadata’s first and only X509Data. IN that way, given the “algorithm” Shib IDP uses, the SP can control which public key the IDP will use and which ciphers/keylengths/… will be used (when it knows its talking to Shib IDP).


I believe the IdP will behave as you describe there.

However, if you are talking about putting multiple entity certs in the KeyInfo that do *not* have the same public key, whether they are in the same X509Data or distinct ones:  I will point out that that is almost certainly a flagrant violation of the meaning of KeyInfo.  It's very clear from the signature spec that a KeyInfo means *a* key (singular).  It can't logically represent multiple keys.

(Usage of those three cert-by-reference elements is intended to help disambiguate the entity cert from the rest of its chain if present, not to disambiguate amongst many entity certs).

I say "almost certainly", rather than "certainly", because the signature spec refers to the singular key in multiple places as the "validation key". When the encryption spec re-uses the KeyInfo, they don't (that I can find) explicitly state that the same rules apply when the key is associated with an encryption operation as opposed to signing and validation. (But they also don't really say much at all either, other than adding extensions).   However, I personally don't see how any other reasonable interpretation is possible.  I think this is more of just an oversight in being explicit. And they do say:

Multiple declarations within KeyInfo refer to the same key.

So that pretty much settles it in my mind.


I believe it also violates the SAML metadata spec, since it seems to assume one entity key per KeyInfo, and hence per KeyDescriptor.  The intention there is if you want to support/represent multiple keys (for key rollover, etc), you use multiple KeyDescriptors.  But that doesn't help your use case.

Not to state the obvious, but if you want to tell the IdP to use a specific key for the SP, then you should just publish metadata to the IdP with only that key only.



 

3.     If I combine 1. and 2.  with SPNameQualifier in the request, asking the nameid value from the IDP to be that attached to a nominated SP (which is specifically not the requesting SP), can Shib IDP be configured to supply a particular user attributes as that value? This would give me authoritative IDP-side account linking, from saml name auth à user’s openid URL, say.


I don't exactly follow, sorry.  Are  you talking about the SPNameQualifier on the NameIDPolicy or the request's Subject/NameID?  And what is the "that value", the SPNameQualifier or the NameID or...?

And I think there may be policy issues though with what I think I do understand: I'm not sure you could necessarily release a NameID qualified with an SPNameQualifier which is *not* associated with the requesting SP - unless you mean a NameID encrypted with the key of the other, non-requesting SP.  And I'm certain we can't do that currently.   You could possibly do it with a custom AttributeEncoder or maybe a Script AttributeDefinitinon or something.  Whether you should or not - I have no idea.

--Brent



 
Reply | Threaded
Open this post in threaded view
|

RE: LoginHandler Mapping/Flow

peter williams-3
In reply to this post by Brent Putman
LoginHandler Mapping/Flow

If it’s a redirect, any reason why it cannot be an URL that invokes sp-initated websso to talk to a remote (upstream) IDP to ”collect credentials” (and authenticate them)? Any reason why the returnTo-identified handler could not rely that (upstream) SAML assertion as the basis for declaring the principal authenticated?

 

If that upstream IDP returns a persistentID with name qualifier, is there any way for the LoginHandler to now induce its own context to use that persistentID (and attach the name qualifier of the upstream IDP) as the nameid in the assertion it is about to  mint?

 

 

From: Brent Putman [mailto:[hidden email]]
Sent: Thursday, January 22, 2009 3:35 PM
To: [hidden email]
Subject: Re: [Shib-Users] LoginHandler Mapping/Flow

 

4) LoginHandler does whatever it wants to do to authenticate the user, e.g redirect to another endpoint (servlet or jsp) to collect credentials, or validate inline credentials directly, etc.

Reply | Threaded
Open this post in threaded view
|

RE: RE: LoginHandler Mapping/Flow

peter williams-3
In reply to this post by Brent Putman
LoginHandler Mapping/Flow

 

 

SPNameQualifier [Optional]

 

Optionally specifies that the assertion subject's identifier be returned (or created) in the namespace of

a service provider other than the requester, or in the namespace of an affiliation group of service

providers.

 

 

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf line 2118

 

I want to populate the SPNameQualfier in the request, expecting the nameid in the response to be a value appropriate for the SP nominated in SPNameQualfier (rather than the requesting SP).

 

Essentially, SP1 asks IDP: put in SAML_SUBJECT the name you would have sent to SP2, when SPNameQualifier=SP2

 

I hoping that Shib IDP might be configured to handle this with a resolver – of which one type can be mapped simply onto an attribute script that comes down to:-

 

Switch(SPNameQualifier) {

Case “Sp1”:SAML_SUBJECT= @ldapattributeX

Case “Sp2”: SAML_SUBJECT=@ldapattributeY.

}

 

 

 

If I combine 1. and 2.  with SPNameQualifier in the request, asking the nameid value from the IDP to be that attached to a nominated SP (which is specifically not the requesting SP), can Shib IDP be configured to supply a particular user attributes as that value? This would give me authoritative IDP-side account linking, from saml name auth à user’s openid URL, say.


I don't exactly follow, sorry.  Are  you talking about the SPNameQualifier on the NameIDPolicy or the request's Subject/NameID?  And what is the "that value", the SPNameQualifier or the NameID or...?

And I think there may be policy issues though with what I think I do understand: I'm not sure you could necessarily release a NameID qualified with an SPNameQualifier which is *not* associated with the requesting SP - unless you mean a NameID encrypted with the key of the other, non-requesting SP.  And I'm certain we can't do that currently.   You could possibly do it with a custom AttributeEncoder or maybe a Script AttributeDefinitinon or something.  Whether you should or not - I have no idea.

--Brent



 

Reply | Threaded
Open this post in threaded view
|

RE: RE: LoginHandler Mapping/Flow

peter williams-3
In reply to this post by Brent Putman
LoginHandler Mapping/Flow

I agree. One can only have one public key (with one or more sets of key-authentication evidence) per SP entity. I’d be being too lazy in using SKI as a dynamic pointer to one of a various EE cert/keys in an X.509Data.

 

Rather, might as well just dynamically populate the X509 data with a cert chain, terminating at the cert whose key=>cipher=>keylength I want used. That is: when talking to IDP1, use RSA for key transport of wrapping key; when talking to IDP2, use KEA for key agreement of wrapping key. In the case of KEA, other KEA-specific objects (e.g. UKMs) are clearly designed to be carried  in the %X509.ANY (which is completely consistent with how Dave Solo would do things and then express it in the type system).

 

As you say, tho, If one publishes a EntitiesDescriptor of several entities, each of which is an SPSSO, and each one has an entityname bound to an ACS URL common to all of them, one can consider the entity name in the request as simply a virtual id for the ACS – where each virtual id can have a unique cert chain in the X509Data.

 

We are used to  federation aggregating a number of SPSSO entities together, one per real organization. But, in the peer/peer model, don’t see why multiple SPSSO entities published by a given Shib2SP install cannot all refer to the same realworld entity, on the same ACS, each operating in its own key management domain which is indicated by publishing a distinct cert chain (and EE public key). I choose which chain I want applied by indicating a different SP (virtual) entityname in the req.

 

(This explains a lot about Ping’s support for virtual SP entityids…to which one CAN add distinct cert chains for xmlenc. Aha!)

 

 

From: Brent Putman [mailto:[hidden email]]
Sent: Thursday, January 22, 2009 5:39 PM


Not to state the obvious, but if you want to tell the IdP to use a specific key for the SP, then you should just publish metadata to the IdP with only that key only.

Reply | Threaded
Open this post in threaded view
|

Re: LoginHandler Mapping/Flow

Chad La Joie
In reply to this post by peter williams-3


Peter Williams wrote:
> If it’s a redirect, any reason why it cannot be an URL that invokes sp-initated websso to talk to a remote (upstream) IDP to ”collect credentials” (and authenticate them)? Any reason why the returnTo-identified handler could not rely that (upstream) SAML assertion as the basis for declaring the principal authenticated?

I'm pretty sure that anything you can describe would fall in to the
category of "what it wants to do".

> If that upstream IDP returns a persistentID with name qualifier, is there any way for the LoginHandler to now induce its own context to use that persistentID (and attach the name qualifier of the upstream IDP) as the nameid in the assertion it is about to  mint?

You could if you wanted to.  Obviously all of this would require custom
code, would be a lot of work to actually get right, and would probably
not be anything supported by any one else.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
[hidden email], http://www.switch.ch

Reply | Threaded
Open this post in threaded view
|

Re: LoginHandler Mapping/Flow

Paul Hethmon
In reply to this post by Brent Putman
Re: [Shib-Users] LoginHandler Mapping/Flow Brent,

I appreciate the detailed reply. Hopefully as I get more comfortable with this I can add some of this to the wiki also. I’ve edited a couple of things but I’m still trying to be cautious on what I add to make sure it is correct.

Thanks,

Paul


On 1/22/09 6:35 PM, "Brent Putman" <putmanb@...> wrote:



Paul Hethmon wrote:
LoginHandler Mapping/Flow
The part I haven’t found yet is where the link from that config to the actual servlet code handling the different types of authentication. The only thing I really see is that the servlet names in web.xml follow a pattern to the attribute values. Then there are the *Handler classes in “edu.internet2.middleware.shibboleth.idp.authn.provider”. So it appears that the handler.xml config causes the appropriate handler class to then load the appropriate servlet class to handle the requested authentication context type.
 

It's actually pretty simple.  The UsernamePassword and RemoteUser LoginHandlers have a configuration property which specifies the endpoint of the associated servlet to which they redirect.  In the wiki doc pages for those 2, see the optional config parameters "authenticationServletURL" and "protectedServletPath, respectively.  The defaults are documented there (which should match what you see in the web.xml).




In my usage, I’m actually replacing the UsernamePasswordLoginServlet class with my own to implement two factor authentication and that is working well. Shib redirects to my servlet and accepts the results just fine. I just want to make sure I understand the flow.
 

That's how the UsernamePassword handler works, yes.


Note however that the fact that these two LoginHandlers use a separate associated servlet, and redirect to it as a part of the authentication process, is entirely an implementation detail of those LoginHandlers.  The RemoteUser one does it because you need to be able to protect a distinct endpoint with your web server or container, rather than the entire IdP context.  The UsernamePassword one does it because it needs to throw up a form, collect creds from the user, and have some place to post those - and it chooses to do that with a servlet endpoint.

A LoginHandler can in general do whatever it wants, e.g. use (possibly multiple) redirection(s) or not; use a servlet or not, etc. 

As to the exact flow, I'll take a stab at documenting this in the Wiki (after I clarify something with Chad about public API), but it's essentially:


1) ProfileHandler determines that authN is necessary and does a servlet API RequestDispatcher#forward to the AuthenticationEngine servlet.

2) AuthenticationEngine servlet selects a LoginHandler, taking into account various things like:  requested and supported AuthenticationMethods; isPassive and forceAuthn; and presence of a previously established IdP Session.  It also does some setup and/or housekeeping of LoginContext and Session.

3) The selected handler's LoginHandler#login(request,response) is invoked.

4) LoginHandler does whatever it wants to do to authenticate the user, e.g redirect to another endpoint (servlet or jsp) to collect credentials, or validate inline credentials directly, etc.

5) The currently running component (e.g.  either the LoginHandler itself or an associated servlet) calls the static method AuthenticationEngine.returnToAuthenticationEngine(request, response), which in turn essentially just does a RequestDispatcher#forward to the AuthenticationEngine servlet.

6) AuthenticationEngine servlet does some LoginContext and Session housekeeping, and then does a RequestDispatcher#forward back to the originating profile handler URL (where the Shib ProfileRequestDispatcher servlet then dispatches to the associated ProfileHandler).

--Brent






-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----

Give a man a fire and he's warm for the day. But set fire to him and he's warm for the rest of his life.

 -- Terry Pratchett, Discworld

Reply | Threaded
Open this post in threaded view
|

RE: LoginHandler Mapping/Flow

Cantor, Scott E.
Paul Hethmon wrote on 2009-01-23:
> Brent,
>
> I appreciate the detailed reply. Hopefully as I get more comfortable
> with this I can add some of this to the wiki also. I've edited a couple
> of things but I'm still trying to be cautious on what I add to make sure
> it is correct.

This is common to wikis but needs to be overcome because people are still
waiting for us to write all the missing documentation and that is NOT going
to happen as long as we're being contracted with to *write code*.

Add whatever you want. If it's wrong, somebody will fix it.

-- Scott


Reply | Threaded
Open this post in threaded view
|

Re: LoginHandler Mapping/Flow

Brent Putman
In reply to this post by peter williams-3


Peter Williams wrote:
> If it’s a redirect, any reason why it cannot be an URL that invokes sp-initated websso to talk to a remote (upstream) IDP to ”collect credentials” (and authenticate them)? Any reason why the returnTo-identified handler could not rely that (upstream) SAML assertion as the basis for declaring the principal authenticated?
>  

It can do anything it wants implementation-wise.  Whether any of this
makes sense to do design-wise and protocol-wise is another exercise...

> If that upstream IDP returns a persistentID with name qualifier, is there any way for the LoginHandler to now induce its own context to use that persistentID (and attach the name qualifier of the upstream IDP) as the nameid in the assertion it is about to  mint?
>
>  


This could be really complex, as Chad said, depending on what you want
to do.  However, I was thinking of a much simpler possibility.  You
could just use the RemoteUser handler and protect the servlet endpoint
with the Shib SP, with a required session. I think this approach has
been discussed before, btw.    Let it handle all the session init,
redirects, etc.  Configure it to expose the NameID (or whatever you
want) as REMOTE_USER.  You can flatten the NameID data, including
NameQualifier, etc, into a string as defined in the SP docs. [1].  Since
you would now have the data available in the attribute resolver through
the principal name, you could do what you want with it.  Only thing
that's not clear off-hand is whether our existing resolver components
would allow encoding of a NameID with a dynamic NameQualifier (or
SPNameQualifier for that matter, as you were asking about in the other
thread).  You might have to write a NameID attribute encoder to do that
(pretty trivial, just look at the existing ones).

If you needed more than just the REMOTE_USER from the SP-supplied data,
you'd have to use a handler + servlet that was aware of more than just
REMOTE_USER and created a Principal or Subject that was added to the
LoginContext.  See the LoginHandler Javadocs for what a handler can and
must do. [2].  I suppose any user data, either individual attributes or
even the full Assertion could be attached to the LoginContext.


Lots of issues here, obviously, I'm not saying this is necessarily a
good idea.  For example the upstream IdP might not be too happy that the
SP is turning around and handing all this off for dissemination via
another IdP....




[1] https://spaces.internet2.edu/display/SHIB2/NativeSPAttributeDecoder

[2]
http://svn.middleware.georgetown.edu/view/java-idp/branches/REL_2/src/main/java/edu/internet2/middleware/shibboleth/idp/authn/LoginHandler.java?revision=2754&view=markup
Reply | Threaded
Open this post in threaded view
|

Re: RE: LoginHandler Mapping/Flow

Brent Putman
In reply to this post by peter williams-3
I see.  I suppose theoretically you could do this.  You have access to
the full request message in the resolver, so could get the
SPNameQualifier.  Assuming you had a way to resolve NameID's from a
datastore, where said SPNameQualifier is one of the search/query
parameters, I suppose you could get it as attribute data.  Then it's
just a matter of encoding as a NameID in the response.  As I said in the
other thread, I don't think our existing NameID attribute encoders
support dynamic qualifiers.

You'd probably also want policy controls.  You wouldn't necessarily want
any SP to be able to request NameID's qualfied by any other SP.  That
implies probably some new functors for the policy engine.

However, this seems to be more in the vain of  account linking or
federation, which implies usage of some of the NameID management or
mapping features of SAML 2, which we currently don't support in the IdP
at all.


Peter Williams wrote:

> SPNameQualifier [Optional]
>
> Optionally specifies that the assertion subject's identifier be returned (or created) in the namespace of
> a service provider other than the requester, or in the namespace of an affiliation group of service
> providers.
>
>
> http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf line 2118
>
> I want to populate the SPNameQualfier in the request, expecting the nameid in the response to be a value appropriate for the SP nominated in SPNameQualfier (rather than the requesting SP).
>
> Essentially, SP1 asks IDP: put in SAML_SUBJECT the name you would have sent to SP2, when SPNameQualifier=SP2
>
> I hoping that Shib IDP might be configured to handle this with a resolver – of which one type can be mapped simply onto an attribute script that comes down to:-
>
> Switch(SPNameQualifier) {
> Case “Sp1”:SAML_SUBJECT= @ldapattributeX
> Case “Sp2”: SAML_SUBJECT=@ldapattributeY.
> }
>
>
>
>
>
>
> If I combine 1. and 2.  with SPNameQualifier in the request, asking the nameid value from the IDP to be that attached to a nominated SP (which is specifically not the requesting SP), can Shib IDP be configured to supply a particular user attributes as that value? This would give me authoritative IDP-side account linking, from saml name auth --> user’s openid URL, say.
>
> I don't exactly follow, sorry.  Are  you talking about the SPNameQualifier on the NameIDPolicy or the request's Subject/NameID?  And what is the "that value", the SPNameQualifier or the NameID or...?
>
> And I think there may be policy issues though with what I think I do understand: I'm not sure you could necessarily release a NameID qualified with an SPNameQualifier which is *not* associated with the requesting SP - unless you mean a NameID encrypted with the key of the other, non-requesting SP.  And I'm certain we can't do that currently.   You could possibly do it with a custom AttributeEncoder or maybe a Script AttributeDefinitinon or something.  Whether you should or not - I have no idea.
>
> --Brent
>
>
>
>
>  
Reply | Threaded
Open this post in threaded view
|

Re: RE: LoginHandler Mapping/Flow

Brent Putman
In reply to this post by peter williams-3


Peter Williams wrote:
> I agree. One can only have one public key (with one or more sets of key-authentication evidence) per SP entity.

No, I didn't say that at all.  You can only have one logical key
represented by a given instance of KeyInfo.   Just keeping things honest
with respect to XMLSig and XMLEnc.

A SAML entity can however logically have many keys associated with it,
and that is reflected in SAML metadata by each entity (actually entity
role) having multiple KeyDescriptors, each with a distinct KeyInfo.

> Rather, might as well just dynamically populate the X509 data with a cert chain, terminating at the cert whose key=>cipher=>keylength I want used. That is: when talking to IDP1, use RSA for key transport of wrapping key; when talking to IDP2, use KEA for key agreement of wrapping key. In the case of KEA, other KEA-specific objects (e.g. UKMs) are clearly designed to be carried  in the %X509.ANY (which is completely consistent with how Dave Solo would do things and then express it in the type system).
>  

If your SP wants to tell (force) different IdP's to use different keys
and/or ciphers, etc, then yes, you must publish different metadata to
each IdP.  You can publish multiple distinct keys for an entity in a
given metadata set as I said above, you just can't really as far as know
force particular IdP's to use particular ones via that mechanism.  In
that case it would be up to the IdP to choose, based on preference or on
what their crypto libraries support, or on some other out-of-band
agreement, etc.


Reply | Threaded
Open this post in threaded view
|

RE: RE: LoginHandler Mapping/Flow

peter williams-3
In reply to this post by Brent Putman
Yes. I'm essentially describing the query...to recover the name an sp has bound to the federated-name (where that binding has normally been achieved earlier through the (unsupported) nameid transaction). Why one SP is "authorized" to then recover the sp-name bound by SP#2 seems to be "out of scope" of SAML. (It would be interesting to get that ratified, and figure what the design team intended...given that query is NOT limited to the affiliation concept)

I was hoping that SHIB IDP had _core_ support for the nameid mapping feature - even if it had not implemented the messaging and protocol engines for nameid.

Assuming Shib had core support, and given the penchant of Shib design team to always use plugin resolver providers, I was hoping that a simple attribute resolver could play the role - in lieu of the real protocol handlers.

> -----Original Message-----
> From: Brent Putman [mailto:[hidden email]]
> Sent: Friday, January 23, 2009 1:10 PM
> To: [hidden email]
> Subject: Re: [Shib-Users] RE: LoginHandler Mapping/Flow
>
> I see.  I suppose theoretically you could do this.  You have access to
> the full request message in the resolver, so could get the
> SPNameQualifier.  Assuming you had a way to resolve NameID's from a
> datastore, where said SPNameQualifier is one of the search/query
> parameters, I suppose you could get it as attribute data.  Then it's
> just a matter of encoding as a NameID in the response.  As I said in
> the
> other thread, I don't think our existing NameID attribute encoders
> support dynamic qualifiers.
>
> You'd probably also want policy controls.  You wouldn't necessarily
> want
> any SP to be able to request NameID's qualfied by any other SP.  That
> implies probably some new functors for the policy engine.
>
> However, this seems to be more in the vain of  account linking or
> federation, which implies usage of some of the NameID management or
> mapping features of SAML 2, which we currently don't support in the IdP
> at all.
>
>
> Peter Williams wrote:
> > SPNameQualifier [Optional]
> >
> > Optionally specifies that the assertion subject's identifier be
> returned (or created) in the namespace of
> > a service provider other than the requester, or in the namespace of
> an affiliation group of service
> > providers.
> >
> >
> > http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
> line 2118
> >
> > I want to populate the SPNameQualfier in the request, expecting the
> nameid in the response to be a value appropriate for the SP nominated
> in SPNameQualfier (rather than the requesting SP).
> >
> > Essentially, SP1 asks IDP: put in SAML_SUBJECT the name you would
> have sent to SP2, when SPNameQualifier=SP2
> >
> > I hoping that Shib IDP might be configured to handle this with a
> resolver – of which one type can be mapped simply onto an attribute
> script that comes down to:-
> >
> > Switch(SPNameQualifier) {
> > Case “Sp1”:SAML_SUBJECT= @ldapattributeX
> > Case “Sp2”: SAML_SUBJECT=@ldapattributeY.
> > }
> >
> >
> >
> >
> >
> >
> > If I combine 1. and 2.  with SPNameQualifier in the request, asking
> the nameid value from the IDP to be that attached to a nominated SP
> (which is specifically not the requesting SP), can Shib IDP be
> configured to supply a particular user attributes as that value? This
> would give me authoritative IDP-side account linking, from saml name
> auth --> user’s openid URL, say.
> >
> > I don't exactly follow, sorry.  Are  you talking about the
> SPNameQualifier on the NameIDPolicy or the request's Subject/NameID?
> And what is the "that value", the SPNameQualifier or the NameID or...?
> >
> > And I think there may be policy issues though with what I think I do
> understand: I'm not sure you could necessarily release a NameID
> qualified with an SPNameQualifier which is *not* associated with the
> requesting SP - unless you mean a NameID encrypted with the key of the
> other, non-requesting SP.  And I'm certain we can't do that currently.
> You could possibly do it with a custom AttributeEncoder or maybe a
> Script AttributeDefinitinon or something.  Whether you should or not -
> I have no idea.
> >
> > --Brent
> >
> >
> >
> >
> >