Shibboleth Developers

[Scott Cantor <>]

> THE PROPOSED AUTHN MODEL
> 
> When the client successfully presented Authn credentials to the 
> server, a security context would be established at the server, and 
> would remain in place until a logout occurred  (via some currently 
> unspecified means), or a second set of Authn credentials were 
> presented (ie "now do a login with these"), or the TCP connection was 
> terminated.

Strike the last part, the TCP connection has nothing to do with this
discussion.

> Authentication can be done at the SSL/TLS layer if the client has a 
> private key and certificate. Authentication would essentially be done 
> out-of-band form the SOAP level session. (PKI is the only 
> authentication mechanism supported by SSL/TLS.)

That's not really true. TLS is also specified for Kerberos, and probably
some other symmetric stuff, though I don't know for sure. In the case of a
browser, probably you can't do it, but I think OpenSSL supports Kerberos,
for example.

> TCP sessions is fast due to caching. An SSL/TLS tunnel would support 
> message integrity and message confidentiality, even if SSL/TLS were 
> not being used for authentication.

Not really, you can't have meaningful confidentiality without
authentication, since you don't know who you're being confidential *with*.
Browser-style TLS is normally based around the theory of server
authentication, but the server is not trusting the client. In practice,
since users rarely validate the identity of the server anyway, TLS is
encryption to no purpose. Pure warm-fuzzy overhead.

> Authentication can also be done at the HTTP layer. Some code in the 
> client must recognize the HTTP responses which indicate 
> "authentication required" and respond appropriately. Unfortunately, 
> HTTP authentication only profiles userid/password. Kerberos is also 
> profiled (via SPNEGO), but support for this is not yet widespread.

I dunno, it's getting pretty close to what I'd call widespread. You've got
Apache and IIS, which cover maybe 95% of the server market, and IE and
Mozilla/Firefox, which is a pretty decent chunk of the browser end...

> SAML/Shib style authentication would have to be done using the SAML 
> Browser profiles (Artifact or POST). Programming these into a client, 
> though, would probably be be a messy business.

The 1.1 Artifact profile is actually pretty clean for a client to do, it
just has to handle redirects.

> 4): SOAP doesn't assume HTTP... do Fedora/ECL?

Note that this question came up on the Liberty list recently, and it wasn't
fully clear whether *they* even assumed HTTP or not.

> THE OPTIONS IDENTIFIED SO FAR:
> 
> 1) SSL/TLS Authn. issues include where would the client get the cert; 
> how to support SMAML/SHIB.

Secure Mammal Markup Language?

> 2) HTTP-Level-Authn: issues include how to support Kerberos and 
> SAML/Shib mechanisms.

Kerberos is the least of your problems, I'd say. Using it is easy,
federating it is hard.

-- Scott