Shibboleth Developers

[Tom Scavo <>]

Good write-up, Bob.

On 11/3/05, RL 'Bob' Morgan 
<>
 wrote:
>
> How much of all this AuthnRequest crap will actually get
> used by anyone?  Have your SPs been clamoring for the
> MobileOneFactorUnregistered authentication context class, or the ability
> to specify the saml:Conditions in the returned authentication assertion?

Yes, GridShib needs this today.  We need isPassive since our clients
are "dumb browser" clients.  We need saml:Conditions since the
lifetime of the assertion must equal the lifetime of the corresponding
X.509 credential, and we need the authentication context stuff since
grid deployments are clamoring for more control over the strength of
authentication.  We may find other AuthnRequest options useful as we
dive deeper into the implementation, it's hard to say right now.

> In fact I would say that SPs in the classic
> multi-organizational arrangement that Shib was designed for (eg OCLC
> accepting campus users) are essentially never going to use any
> AuthnRequest features for a long time...

Perhaps, but Shibboleth is being used today in non-classic scenarios
(e.g., non-browser profiles) and this trend is accelerating.  SAML
authorities are increasingly being employed in ways the creators of
SAML (that's you, Bob :) declined to specify.

> So maybe there really is an expedient subset of AuthnRequest factors that
> could be exposed via an API to an external-SSO provider, post-parsing of
> the full AuthnRequest by the Shib 2.0 IdP.  I suppose these might be
> ForceAuthn and IsPassive, maybe saml:Subject, maybe a set of authn context
> class URIs (so we can get our SecurId mode at UW).  If, say, CAS,
> Pubcookie, A-Select, and CoSign folks can agree on this, and agree to
> write handlers accepting these params and mapping them into functions of
> these systems, then maybe we can all get what we want.

Instead of mapping the AuthnRequest schema onto yet another API, why
not simply pass the SAML itself and leave it to the SSO provider to
parse.  In the end, everyone will consume and produce SAML, right? ;-)

Tom