Silently try more then one login handler with UnsolicitedSSO

[Douglas E. Engert]

On 4/29/2013 1:07 PM, Henry B. Hotz 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.
>

No, the https://wiki.shibboleth.net/confluence/display/SHIB2/Kerberos+Login+Handler
does its own SPNEGO.

The https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler
gets the client certificate used with the Apache SSL.



> 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.)
>

The above two handlers jsp pages can be merged with the login.jsp
used for PasswordProtectedTransport.

This gives the user the choice of which one to use. (If it fails, the user
may have to start over. The Kerberos login handler also sets some cookies
for auto_login to just try it first. Its the error handling if this fails
that I am having problems with.

> I agree the normal login page is more informative than the usual basic-auth prompt.  I could live with either, if passwords are an acceptable alternative.
>

> 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 Kerberos handler has some code to provide the Kerberos principal.
The X509 handler has code to provide some mappings.
I have added code to return the subjectAltName:otherName:msUPN if present, and
to return a string that would match what AD has for AltSecurityIdentities.

The attribute-resolver.xml can then use the principal, username of one
of the X509 attributes to look up a user in AD.

Each handler sets an AuthenticationMethod:
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport

The Kerberos handler sets:
urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

The X509 handler sets:
urn:oasis:names:tc:SAML:2.0:ac:classes:X509

And with the X509 mods and a smart card:
urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI


> On Apr 25, 2013, at 8:18 AM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>
>> On 4/25/13 11:13 AM, "Douglas E. Engert" <deengert at anl.gov> wrote:
>>
>>> Now the issue is how to get the Kerberos Login Handler to
>>> silently try SPNEGO, and if it fails, fall back to our normal
>>> login page.
>>
>> I don't know anything of how SPNEGO works, but perhaps one could implement
>> the SPNEGO via Apache and mod_auth_kerb, and have a custom login handler
>> that looked for REMOTE_USER and if not set operated like the existing
>> UserPass handler.
>>
>> I have been led to think that SPNEGO in general has no effective error
>> handling behavior and that if it doesn't work for everything it basically
>> becomes a problem, but if not, the above might work.
>
> mod_auth_kerb will fall back to a basic auth prompt if SPNEGO/GSSAPI fails (and it's configured).  It also logs some useful information.  I've never heard of anyone doing anything fancy/useful with the error pages sent back to the user though.
>
>> -- Scott
>
> ------------------------------------------------------
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444