Two factor authentication for shibboleth

[Douglas E. Engert]

On 2/19/2013 1:02 PM, Mike Wiseman wrote:
>
>>
>> Has anyone had any experience integrating Shibboleth with two factor authentication?
>> The two vendors we are looking at, which claim they can work with shibboleth, are
>> RSA and Safe-Net. If you have any experience with these and shibboleth, please let
>> me know if you have been able to make it work.
>>
>> Thanks!
>>
>> Jared
>>
>
> We are planning to deploy the X.509 login handler and use the SafeNet 5100 device (formerly eToken?). We've done some dev testing and configuration that included using the email address of the cert to do the LDAP lookup but need to firm up a few things such as whether to run two user interface pages - one for username/pw, the other for X.509. We'll also be agreeing on the cert extensions, instead of depending on the email address as the unique identifier, we'll pick a more persistent value.
>

We are using the X.509 handler, and have a combined login page
that has an extra button for X.509 login.

When used with a smart card we assert:
  urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI

The certificates are either smart cards or AD issued auto-enroll
certificates. Currently in both cases the certificates have a
subjectAltName:otherName:userPrincipalName

This method is building on top of existing AD 2003 and XP use of
smart card login via Kerberos PKINIT that maps a userPrincipalName
to one account.

(For Shibboleth the certificate is validated on the IDP, not AD.
Users with smart cards must have the cards registered with our AD
before  they can be used with the IDP and they can use them for
login too.)

Ldap is use to search AD for the userPrincipalName and the
samAccountName of the account is returned. The userPrincipalName
is unique across the forest and is single valued.

Mods to he X.509 login handler to do the above were submitted 2
years ago.


We also have additional mods which are being tested to take
advantage of AD 2008 and Windows 7 use of a many-to-many mapping
of smart cards to accounts that does not rely on the userPrincipalName
being in the certificate.

In this case, AD expects to have the certificate subjectName
and issuerName stored as a string in the altSecurityIdentities
attribute of an account.

(Microsoft did not follow any RFC standards in converting the
subjectName and issuerName to the altSecurityIdentities
so our mods may need changes if we find some strange case.)

For AD smart card login, W7 will ask for a "hint" as to
what account is to be used. (On Unix with Kerberos PKINIT
its the username.)

Mods to the X.509 login handler take the certificate subjectName and
issuerName convert to a string, escape any LDAP special characters and
return the string to be used in an LDAP search of AD for matching
altSubjectSecurityIdentities and hint. If found the samAccountName
of the account that matches. if no hint is given by the user and a
search returns a single samAccountName it will be used.


All the smart cards we are willing to accept have the Microsoft Smart Card
login EKU  1.3.6.1.4.1.311.20.2.2 and all the non-smart card certificates
we are willing to accept are under our control and do not have the EKU.
So we can indicate a smart card was used to authenticate in the assertion:

  Shib-Authentication-Method=urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI
  Shib-AuthnContext-Class=urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI

An SP can use this as needed.


> Mike
>
>
>
> Mike Wiseman
> Manager, Information Security
> Information + Technology Services
> University of Toronto
>
>
>
>
> --
> 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