Wednesday, January 28, 2009

Custom Smart Card Authentication and SharePoint

One of the great new features of SharePoint 2007 was the ability to utilize multiple means of user authentication: Active Directory, LDAP, SQL, and more. This is nothing new, and since the advent of MOSS 2007/WSS 3.0 the use of non-AD authentication via Membership Providers has been well documented.

What if you need to use PKI (Public Key Infrastructure) certificates and/or Smart Cards (like Common Access Cards, aka CAC)? There are a few ways to do this, depending on how the user certificates need to map to your account store. If you use Active Directory, there are built in ways to map certificates to users and have IIS handle the handshake. Or you can use a third-party system or SSO. This assumes you have a defined user directory and pre-defined certificate mappings.

But what if you need to accept PKI/Smart Cards, but do not have a master user directory (AD, LDAP) of everyone who will attempt to access the site?

16 comments:

I was under the understanding that to be able to use AD with smartcard certificates that you could have it automatically map to one that looked at a smartcard for a UPN that would map to a user object UPN but otherwise if you weren't using UPN you'd require mapping the certificate individually for each individual user. Is this the problem that you're attempting to solve?

I hear that Windows Server 2008 may bring a solution for this.

Perhaps we should get together sometime to work through this idea and work out a solution. Up for a partnership?

I must say that it is random to see a fellow Watkins Mill grad tweeting and blogging on PKI. Ironic that two WMHS grads are in the same tech? Anyhow, good post and random finding you on the web (via twitter).

If you setup SharePoint to use your LDAP as a membership provider, in theory you could have users log in without a username and password using their LDAP account. If:

You use an HTTP module, ISAPI, or a custom ASP.NET login page through the SharePoint membership provider. That would read the PKI/CAC information, pass it through the membership provider to log the user on, and redirect them to SharePoint. Depending on how you write the code, you can forgo asking the user for any username or password. (Just make sure you trust the PKI information you are receiving.)

For example, using the ASP.NET Forms Based Autentication in SharePoint, you can get this require login info to pass through the membership provider and grant the user a logon session in SharePoint.

Is there a way to map an authenticated user, based on his X.509v3 user certificate fields, to a Role Bases Access Control concept in the case of Sharepoint?

So based on Organization and/or Organizational Unit, and/or Locality etc?

This way actual unique user accounts would not need to be created in advance, or on their first login attempt.

I'm getting loads of questions in reference to Sharepoint Access/SSO, from people who use a solution where very short life (ie 4-8 hour valid) user X.509 certificates are provided, pushed and installed on the fly to an end-user. Authentication used to obtain these certificates can be LDAP/AD, but also Oracle DB, MySQL, Radius etc.

Hey Joel. I'm very interested in your solution for using CAC/PKI to authenticate and pass that to SharePoint. I have an existing website that uses CAC/PKI infor for login. The login are mapped to accounts in SQL. From here, I want to pass that info to SharePoint and allow the user to login. I'm reading through the concept, but I'm uncertain on how best to implement it. I would like to know what your solution for this is. Thanks.

We did this for the Air Force using Big-IP F5 load balancers, custom irules and Http Modules in SharePoint calling a sql membership provider. It allowed use to have single sign-on and utilize SharePoint document libraries and webdav for our apps.

Hi. I am tasked with coming up with a solution to similar to this for several science labs in the DoD. I don't have any pocs so I'm scouring the 'net but everything is sps 2010. I will have to redesign and re-architect security as well as design/taxonomy of several web apps. Unfortunately none of that will matter until I aquire the information to setup CAC authetication and AD LDS for external users (just in case they cannot be sponsered by a DoD employee). Am I going to run into the issue of being forced to extend the web app and have different pages for each type of user logging in or can I just have everyone go to one login page and choose the way they want (CAC\user name password stored in AD LDS) to login and then proceed to landing page? This might be important because the stakeholders might not like the idea they have to give out different urls depending on how the person will autheticate to the site. If a user receives a link in an email and they have to authenticate before going to linked page will they be redirected to default/landing page or link from email. If they get redirected to default/landing page what do I have to do to make sure user ends up at intended linked site from the email? Thanks in advance

With Claims based authentication in SharePoint 2010, you can have one URL for all authentication types. If you use classic authentication you still need separate URLs unless you can find a way to auto-select via a proxy or something (I'm just throwing the idea out there--not sure if it's possible).

That said, Claims is not necessarily a perfect solution. I've heard it can be a pain to set up, and some things get broken in SharePoint when using Claims.