Shibboleth Developers

[Alistair Young <>]

Thanks for that Nate, most interesting. It's perhaps a bit more than  
I was thinking of.

The scenario is, we have a distributed SP, in that the central engine  
is remote from guards that provide Shibboleth protection to webapps.  
A guard will block a request to a webapp and get the engine to do all  
the Shibboleth profile stuff to get the user authenticated and get  
their attributes. It does this via a web service on the engine.

The guard redirects to the WAYF, whose location is returned by the  
engine via a web service. The guard sets the shire parameter to point  
to the engine, not the guard. The engine then gets the  
AuthenticationStatement, not the guard.

The engine then gets the attributes from the AA and when ready  
signals to the guard to come get them via a web service on the guard.

The point of the handle, originally sent to the IdP in the Shibboleth  
GET request, is for the guard to identify itself. This handle ends up  
in the SAML Response coming from the IdP to the engine.

This all happens through cookies at the moment but if we wanted the  
engine to handle Shibboleth transactions for mutliple domains it  
wouldn't work. Hence the message-level identification.

Ideally we'd want the handle to end up in a SAML element in the SAML  
Response containing the AuthenticationStatement. That way an engine  
knows which guard it's working on behalf of.

It basically boils down to:

http://some.idp.url/SSO? 
shire=...&target=...&time=...&providerId=...&requesterId=GUARD_ID

<samlp:Response>
  <saml:AuthenticationStatement>
    ..
   <somenamespace: requesterId > GUARD_ID</somenamespace: requesterId >
  </saml:AuthenticationStatement>

Alistair

On 22 Jun 2005, at 17:03, Nate Klingenstein wrote:

> Alistair,
>
> What you describe to me seems to boil down to something similar to  
> having a second source of authentication; you're associating the  
> user with a second principal(of some vague incarnation) at the  
> original proxy.
>
> You can do IdP-first interactions now just fine.  The missing piece  
> is the capability to include additional authn/z information from a  
> third party in the returned assertions.  Additionally, you'll  
> probably want to handle this information as full-fledged assertions  
> for trust purposes.
>
> You suggest doing so using a style of a push-proxy model.  This  
> would feed additional information into the IdP along with the  
> AuthenticationRequest element which corresponds to a specified  
> entity, such as inclusion of an existing authentication assertion  
> with a handle or ID already in it, and count this as a sort of  
> second identifier for the user.  It could be done in any number of  
> ways.  The ideal and probably simplest course of action in that  
> instance seems to me to be receiving, caching, and then including  
> this assertion with the final returned attribute or authentication  
> assertion to avoid possible 3-tier stuff, again in any number of  
> ways.  There are likely to be HTTP GET issues trying to accommodate  
> the large amount of data in the request.
>
> As an alternative, SAML 2.0 has a proxy protocol which is part of  
> the IdP Extended set of requirements.  This works in a pull fashion  
> though; accepting a request from an SP or other authentication  
> scenario which you can't completely handle and offloading it  
> partially or entirely to another IdP through a backchannel flow,  
> then generating a statement from the combined results.  There's as  
> always any number of ways to package the information here.  In this  
> case, the IdP recognizes a request bound for this particular SP and  
> realizes it will need to pass more information; in this case, that  
> additional handle or ID you describe.  It would then contact that  
> third party to acquire that information if possible through a  
> proxied request mechanism and bundle that in the returned  
> assertion, again in any number of ways.  This might be more robust  
> and require fewer hops for the browser agent.  Then again, it might  
> not.  It depends on the details of your scenario.
>
> As an ugly, temporary kludge, you might find a way to use the  
> attribute resolver to suck stuff out of a database at the proxy.
>
> Do you have more details?  Is this helpful?
> Nate.
>
> On Jun 22, 2005, at 9:40, Alistair Young wrote:
>
>
> > At the moment, the shibb IdP gets a request from a WAYF or SP with  
> > the shire, target etc params. I was wondering if it would be  
> > possible for it to also accept another "handle" or "id" parameter  
> > which it translates to a SAML element, to be sent with the  
> > AuthenticationStatement it generates.
> >
> > The use case is where the SP hasn't redirected to the WAYF/IdP.  
> > Instead, something else has done it on it's behalf. The SP  
> > receives the SAML Response from the IdP though. The "handle" or  
> > "id" or whatever would be used by the SP to match up the incoming  
> > Response with the original proxy.
> >
> > Would this be feasible for shibb? Is there a SAML element that  
> > could be used? I've done this using cookies but it would be better  
> > to have something at the message level, allowing cross domain  
> > proxying.
> >
> > ta,
> > Alistair