Shibboleth Developers

[Peter Williams <>]

Consider a more natural gateway setup, one that is very real for us (just 
within the web farm).

User does shib websso to SP, which creates Shib SP session.

The shib'ed app is accessed, and now its programming retrieves the ("used") 
assertion by reference.

The server  side app needs to leverage several web calls (by design), where 
access control is enforced by the several web service providers operating on 
the internet (and who do participate as domains in an active directory 
forest, not do they have ADFS trusts, not do they have or Kerberos trusts)

Thus, webapp seeks to create an "open" security token that the "Shib SP" 
asserts (as _asserting_ party) has the shib assertion's subject value as the 
token's saml subject (and which perhaps maps attributes too - from the app 
context and/or the shib session and/or the shib assertion).

The reality is that websso-powered web apps are increasingly leveraging 
supporting business objects, which often have a web service API. Let's assume 
that the Shib SP and the STS client are formally under the same domain 
authority, being "being endpoints in the same communication stack with the 
same thread identity as far as the TCB is concerned".

There seem two obvious choices:

        1. the app itself simply impersonates the user (from the shib2 
session, creating a token than can be translated into the saml2 security 
token).

        2. the app "presents" the shib assertion for "translation" in act of 
delegation (rather than impersonation_)

In case 2, I can see the webapp naturally hosting the subject's signing key, 
for use in HOK confirmation. This is similar to how many webapp sites used to 
host the signing keys for cardholders performing the VISA/Master SET protocol 
(rather than requiring the browser to have native SET protocol support). 
Folks would bind the SSL client cert to the SET "hosted" signing key, rather 
like one might bind one's cardspace card to an openid OP.

Thanks for the pointer on uportal. I'll look at it in detail. But we do need 
to make something work with open systems from multiple vendors (today). This 
may mean creating a stepping stone on the way to realizing the "more 
comprehensive" security concept underlying uportal.

> -----Original Message-----
> From: Scott Cantor 
> [mailto:]
> Sent: Wednesday, April 15, 2009 9:50 AM
> To: 
> 
> Subject: RE: [Shib-Dev] handing off assertion from websso to STS
> translating to saml2 profile of security token
>
> Peter Williams wrote on 2009-04-15:
> > Is it reasonable for an SP to give the (now IDP-side) STS a Shib2
> websso
> > assertion for "token" translation - and then attach the resulting
> token to
> a
> > web service call?
>
> In their current "undecorated" form, no, that's not reasonable. The
> STS,
> IdP, or whatever you want to call it is a relying party in that
> exchange. If
> you hand it an assertion, it is required by any reasonable reading of
> the
> standard to evaluate the assertion in that light, and there are at
> least a
> couple of criteria by which it should rule the token invalid:
>
> - the AudienceRestriction won't be valid
> - the Bearer confirmation can't be satisfied because it will have a
> Recipient value pointing to the SP
> - the Bearer confirmation may also be expired in some cases
>
> If you want to do delegation, you do something like we have proposed in
> the
> uPortal integration project. It doesn't have to result in Liberty-
> defined
> interactions, but the up front decoration required is essentially the
> same.
>
> There's probably little reason not to require Holder of Key, since if
> it's
> an SP performing the request, you can determine the key from its
> metadata.
>
> -- Scott
>