Shibboleth Developers

["Scott Cantor" <>]

>    Subject
>    NameIDPolicy
>    Conditions

I think it's questionable whether these are really relevant to the SSO
handler. They're relevant to the assertion content coming back, but I think
the goal of the SSO handler is to authenticate the user and provide the
result in some canonical form, just as Apache does today. We rely on the
SAML-aware handler to actually construct the assertion requested, and that
includes constructing the proper NameID.

> multi-element things in themselves ...).  Since several of these 
> elements/attributes might appear together in a request, for each unique 
> combination to be handled by a distinct location would require, I dunno, 
> maybe a billion locations.  So if any significant number of these factors 
> is to be handled by a non-built-in SSO scheme, I can't see any alternative

> but to pass the information to it rather than relying on distinct 
> locations to be configured.

I think it is important that the dispatching based on AuthnContext be in the
Shibboleth code, and not external. That gives us the ability to properly
configure the precedence rules in use. Of course, most deployments will only
support one or two context classes, so it's not a matter of mapping 25 of
them, it's just mapping the ones supported.

> different than if the site used Shib 2.0 natively.  Assuming Shib 2.0 does

> a halfway decent job of handling AuthnRequests, the non-built-in scheme 
> will be only a subset of what Shib 2.0 can do (though of course it might 
> be preferable to a site for other reasons despite this).

It's protocol translation and I'm not a big believer in it, I never have
been.

> So here's the deal.  Shib 2.0 comes out.  The IdP has all this cool 
> AuthnRequest stuff in it.  If the IdP doesn't have any provision for 
> invoking a non-built-in scheme, then a site that has such a scheme (CAS, 
> Pubcookie, A-Select, etc) already deployed has these choices: (1) put the 
> IdP behind local SSO just as they do now, and give up the AuthnRequest 
> features;

I think you still *have* to configure it using the built-in mechanism, but
you have to configure it for the LCD of what it can support. So the IdP has
to detect and fail on requests involving AuthnRequest settings the handler
can't support. For IsPassive that's fine, since that's really an optional
thing to actually do. For ForceAuthn, it means SPs will get an error back.

> (2) deploy the Shib 2.0 native SSO alongside or instead of their 
> existing one; (3) hack on the Shib 2.0 IdP to somehow call their existing 
> scheme, obtaining a subset of AuthnRequest features.  So if Shib *did* 
> have provision for invoking a non-built-in scheme, the difference would be

> that (3) would be a little easier; but it would still be a subset.

I think Chad's proposal supports (3). I don't know what we could do to make
that easier unless we invent a non-SAML protocol to carry the bits, which
just moves the work out of Java and into the other SSO system. I don't see
that as good because it forces every other system to explicitly change, and
some may not be as extensible as Shibboleth.

> 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.

This isn't an API, it's a protocol. It could be argued it's just another
SAML binding that might not carry the message as XML, and might not support
the full schema.

I suppose I'm more confident than you are that there really is a minimal
amount of the data that would really be needed by the SSO system.

> 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.

Could you describe why you think the Subject or AuthnContext information
would need to be handled externally to Shibboleth?

I suppose Subject might come up if you want the SSO system to detect the
mismatch, but that's certainly something that the Shibboleth piece *could*
do after the fact. Given the use case for using Subject at all in the SSO
profile, I don't think it's a big enough deal to worry about.

-- Scott