Silently try more then one login handler with UnsolicitedSSO

[Cantor, Scott]

On 4/29/13 2:07 PM, "Henry B. Hotz" <hotz at jpl.nasa.gov> wrote:

>Without looking in detail, I *thought* the kerberos login stuff leveraged
>mod_jk, and the mod_auth_kerb stuff.  And I *thought* that it should be
>possible to use client certs via mod_ssl's +FakeBasicAuth option as an
>alternative.

Can't be, it's in Java.

>
>Not true, I gather.  Since I, too, want to accept client cert's as an
>alternative to Kerberos tickets, should I assume the Kerberos login
>handler is *not* the way to go.  (Yes, that is a question.)

I think it's either you write your own by copying bits of others, or push
this to Apache.

>So, where should I map X.509 DNs and Kerberos principals to usernames,
>and how do I create an attribute which says how the original
>authentication was done?

The login handler is responsible for deciding what to report as a
username. If you don't deal with it there, then the rest of the system
will have to accomodate attribute lookups using all those different
flavors of identity. I'm not aware of any support for principal mapping
inside of any existing login handlers, so this isn't done for you, in
short. Another requirement for a custom handler.

Attributes aren't used in most cases to describe authentication, that's
what AuthnContext is for. That's set based on the authenticationMethod
string used to dispatch requests to the login handler and returned from
it. Existing handlers cannot accomodate a single handler returning
different method types.

If you need something fancy, you need to write your own handler. There's
not much else to be done.

-- Scott