Shibboleth Developers

[<>]

I agree with Nate that native support would be nice, since that would allow proper population of AuthnContext.  The federation I am working with currently has a policy level rule requiring all IDPs to do CCA, but some members have resources they would share even if users did not authenticate with CCA (so moving forward, it would be nice to have that flexibility).

 

Nate, did you test this SSLUserName feature?  It works fine with PHP, but the RemoteUser handler in Shibboleth always gets the DN (not sure if Tomcat is somehow overriding the RemoteUser with SSL_CLIENT_* stuff).  I can work with the DN (it’s a bit less convenient), but I was curious if this worked directly for you.

 

From: Nate Klingenstein [mailto:]
Sent: Thursday, January 31, 2008 3:10 PM
To:
Subject: Re: User Authentication on the IDP?

 

Oh. Recently, with "recent" measured in x.509 years, added:  SSLUserName SSL_CLIENT_S_DN_CN

 

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html

 

Totally missed that in all my reading earlier.  Tomcat may have something similar that has been added in the time since Dartmouth felt it necessary to implement a filter itself.

 

I would still like to see the IdP handle client certificate authentication itself, if for no other reason than its intelligent integration with AuthnContext, to the extent AuthnContext is intelligent.

 

On 31 Jan 2008, at 20:00, Scott Cantor wrote:

I think it's pretty much the same, only the actual resource you need to

protect with REMOTE_USER has changed (and no, I don't know what that is, but

it would be the same as using CAS or pubcookie or whatever).