Background on Pass-thru Authentication for April 3 Telecon

[Hal Lockhart <hal.lockhart@entegrity.com>]

This message provides background for one of the issues to be debated and
decided during the April 3 teleconference.

Should SAML define a means for pass-thru Authentication?

The current SAML requirements include the following non-goal: 

SAML will not propose any new cryptographic technologies or models for
security; instead, the emphasis is on description and use of well-known
security technologies utilizing a standard syntax (markup language) in the
context of the Internet.

This has generally been interpreted to mean that SAML will not define any
new method for a System Entity to authenticate itself directly to an
Authentication Authority.

However, it has been proposed that SAML define a means by which a
Credentials Collector could pass credentials to an Authorization Authority
on behalf the principal being authenticated. Another name for this scheme is
Proxy Login.

During the first F2F, there was an extended discussion around a motion to
explicitly exclude Authentication from SAML. During the discussion, the
diagram on the whiteboard was amended to include the concept of pass-thru
authentication and the Credentials Collector. After the vote was taken many
of those present were under the impression that all types of authentication
had been dropped from SAML. However the minutes say that the issue was
referred back to the use case subgroup.

The use case subgroup has some members who support and some members who
oppose the inclusion of pass-thru authentication in SAML. After some debate,
we are referring the issue to the entire TC for resolution.

Arguments for:

Pass-thru authentication is widely used today. For example, a web server
using basic authentication does it. Most Access Management or PMI products
provide this capability in some form. The RADIUS protocol supports it as
well.

In a SAML context it would be useful for Portals, outsourced user management
and generally any environment where it is desirable for authentication to
occur in multiple places while the Authentication Authority (particularly
its repository) is centralized. It has also been observed that a nice side
effect would be that the SAML scheme could be used internally within
products even in the absence of a need for interoperability.

Arguments against:

Defining such a scheme for a variety of authentication methods would be
technically very difficult. Pass-thru authentication presents little
difficulty for username/password, but supporting multiple methods presents
several types of problems.

Cryptographic authentication protocols, e.g. SSL, Kerberos assume the
entities communicating with each other directly possess secret keys. The
need to communicate these keys with a remote entity undermines the security
of the protocol, and in some cases, e.g. keys in a smartcard, may not even
be possible. Further, the result of the authentication is the possession of
some temporary information, e.g. session keys, which is necessary for
continued use of that identity. Finally, the fact of not needing to consult
a central authority is often cited as an advantage of PKI, but pass-thru
authentication would eliminate this advantage.

Most products today "solve" this problem by redefining the trust
relationship depending on the type of authentication used. For example, for
user name/password, the Authentication Authority is authoritative, but for
PKI, it relies on the web server to vouch for the correctness of the
authentication. If a user is permitted to authenticate using multiple
methods, this means that the trust relationships would be different for the
same user authentication to the same infrastructure, depending on the
authentication method the user chose.

This approach is acceptable within a single security domain. However, since
interoperability boundaries will often correspond to security domain
boundaries in a SAML environment, this seems very undesirable. It would
imply that the entity signing the Authentication Assertion was not even in
the same security domain as the entity actually verifying the identity.

A reasonably comprehensive approach to providing for pass-thru
authentication in SAML would include support for a variety of other
protocols as well, including: token-based one time passwords, various types
of biometrics, MS challenge/response, and biometrics combined with PKI. Each
of these is likely to present additional design difficulties. It is worth
noting that RADIUS does not attempt to support PKI or Kerberos.

Possible Resolutions:

1) SAML should define a generalized method of pass-thru authentication that
supports several popular types of authentication and is extensible to
others.

2) SAML should not define a method of pass-thru authentication.

3) SAML should define pass-thru authentication only for username/password
authentication.

4) The Assertions and Protocols subgroup should be directed to develop a
generalized method of pass-thru authentication. Once this has been done, the
TC will vote to drop or maintain this feature.