Shibboleth Developers

["Scott Cantor" <>]

I think we need to separate credentials collection from actual user
authentication. Nobody is saying "user accounts and passwords will be inside
the IdP". I mean, they could be, but....

> I second Jim's thought. In transitioning away from application-based 
> authentication and consequent identity-based access control habits, 
> we've all learned over the last few years that it's important to keep 
> proprietary authentication mechanisms out of applications.

Certainly, but the IdP is not just an application, it's a web authentication
service. If an authentication service isn't a reasonable place to implement
credentials collection...

> I understand  that session management and SP-originated obligations on 
> authentication are part of SAML2, and that arguably the easiest design to
> implement them is founded on incorporation of authentication into the IdP
- a 
> proprietary SSO system, if I understand your terms above.

The IdP is a standards-based SSO system, not a proprietary one. But either
way, it's not about "easy" or "hard", it's about what's possible. If an SP
says IsPassive or ForceAuthn, you *cannot* conform to the spec unless you
know how the credentials collection step will be done, which means one of
two things:

- implement the process yourself
- tell the external service what to do

Either of those is possible with Chad's design, but we cannot control all
the possible ways to do the latter. So we're saying that we can implement
AuthnRequest-aware handlers that can deal with most of the authentication
approaches out there or people can write their own glue that translates a
SAML AuthnRequest into the right parameters for their flavor of
authentication service. That shouldn't be our job.

One question to be asked is whether some existing Java framework could be
used to handle the process, and I don't know the answer to that. Ideally
yes, I guess, but you don't see Tomcat using JAAS by itself, so the
precedent is that everybody rolls their own.

> But I think it's terribly important to at least seriously examine
alternative 
> designs that are premised on use of authentication services external to 
> the IdP, ie, in which IdP and (nearly) arbitrary site authN are
composable.

There is no alternative design I can see offhand without constraining what
you're calling "arbitrary". But to me, all the actual authentication
services (Kerberos, LDAP, AD, SecureID, mapping client-certs to users) are
effectively external. It's the code that interfaces with the user that we're
talking about.

Using an external SSO system means that it controls the UI, and that means
the SAML aware portion of the IdP needs to influence the behavior of the SSO
system. That's not something we can design for without any boundaries.

-- Scott