RE: PassThruAuthNMayHarmInterop

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

Stephen Farrell wrote:
> Omitting pass through authentication from SAML's scope means 
> that SAML fails 
> to meet the goal of specifying a muti-vendor interoperable 
> PEP/PDP protocol. 
> 
> This also means that application developers cannot write the 
> PEP side with 
> the expectation of working sensibly with authorization 
> vendors on the PDP 
> side, similarly authorization vendors will have to continue 
> to write PEP 
> plug-ins etc for each and every application (and version! yuk!).
> 
> I think that that's a very bad outcome.

First let's get the terminology straight. What Stephen means is that he
believes an architecture which bundles together a PEP and a Credentials
Collector is a desirable approach. Since SAML is not going to standardize
the Credentials Assertion, the interface between this entity and the
Authorization Authority will not be SAML specified. I think that he is also
implying that the Authentication Authority and PDP (and perhaps Attribute
Authority) will be bundled together, otherwise the lack of passthruAuthN
doesn't seem too serions to me.

My first response is: nobody has said that it wouldn't be a Good Thing to
standardize the CC to AuthZ Authority interface, only that it is infeasibly
difficult. I am still waiting to see an outline of a design that meets my
simple requirements. I note that none of the existing standards that do this
kind of thing: Radius, SASL & GSSAPI support PKI channel protocols. [GSSAPI
provides passthruAuthN assuming an unspecified transport protocol.] This
suggests that I am not the only one who thinks this is hard.

In order to support both U/P and SSL w/client certs, there are basically two
approaches. The first is to say that sometimes the CC Authenticates and
sometimes the AuthN Authority does. In other words, the CC is actually a
AuthN Authority for some types of AuthN (PKI). This approach implies one of
two things. In choice one, the CC has to be able to issue (and perhaps sign)
AuthN Assertions, thus defeating the goal of a simple lightweight component.
Choice two is to define the CC to AuthN Authority protocol to allow a CC to
simply assert to the AuthN Authority that an authentication has occured
without proof and cause the AuthN Authority to issue an AuthN Assertion.
This may be reasonable in a single security domain, but seems unacceptable
in the cross domain case.

The other major design approach, (which no one at the F2F seemed to have any
stomach for) is to essentally weaken the PKI protocol by sharing private or
session keys between the CC and AuthN Authority. This could be done in a
variety of ways, but all seem unattractive in both theory and practice.

Of course, all these difficulties can be overcome by restricting
PassThruAuthN to just U/P (or just the SASL schemes) but this alternative
has not attracted any support in the meetings or on the list.

Now let's look at what we are left with. Implementors have several choices.

1. Clients authenticate directly to an AuthN Authority using a standard
protocol like http basic auth or SSL w/client certs and it issues
Assertions. (like passport)

2. Clients authenticate indirectly via a CC which uses a proprietary
protocol to communicate with the AuthN Authority. The CC and AuthN Authority
between them issue an AuthN Assertion in some convenient way. In other
words, from a SAML perspective they are a single entity.

3. Clients authenticate indirectly via a CC which uses a standard protocol
such as SASL or RADIUS to communicate with the AuthN Authority for those
authentication methods supported by those protocols. The CC and AuthN
Authority between them issue a AuthN Assertion in some convenient way. In
other words, from a SAML perspective they are a single entity.

Finally, I would not be averse to adding PassThruAuthN to SAML in future (if
somebody can suggest a way to do it.) I assert (without proof) that unlike
sessions, where their existence potentially affects the semantics of all
other assertions, PassThruAuthN can be added to SAML without affecting
anything else.

Hal