Shibboleth Developers

[Nate Klingenstein <>]

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