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?

The Concept:
  • Use a custom ASP.NET Membership provider to accept and read PKI certificates (using IIS)
  • Create and login to a NEW account (AD, LDAP, SQL)
  • Forward the user to the SharePoint site.
Very similar to this idea from Adam Buenz.

Easy? We shall see.


Dan Usher said...

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?

Joelsef said...

Our problem is slightly different.

We aren't using AD and won't have a pre-populated user directory. We need to create new accounts on the fly.

Certificate holders of a certain type will be allowed in automatically.

Other certificate holders will be able to fill out a sponsorship application. Once they are approved, they will be able to access the site.

Let's partner up.

Tanner said...

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

-Kevin Heald

Joelsef said...

Thanks, Kevin!

PKI is good stuff, especially our environment where we don't have one central user directory/LDAP/Active Directory but do have a common authentication platform with the certificate authorities.

Anonymous said...

We are AF contractor and we are trying to implement the same CAC card to our Sharepoint site. Do you guys have any suggestions like how to implement it.

Joelsef said...

Continuing comments from ...

Joelsef said...

From the earlier post:

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.

Part 1
Part 2
Part 3

Plus customizing the login page to handle the SSO or PKI information using ASP.NET: Customizing the login page

and doing the FBA login with that information.


Michael vd Sman said...

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.

Anonymous said...

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.

Anonymous said...

Joel. I am interested in your solution for using CAC/PKI. Can you please share your solution/concepts?

Thanks! Kasi

Joelsef said...

Hi Kasi,

Let me see what I can post.

In the meantime, we covered it in a little more detail in our SPSDC presentation from May 2009.


Anonymous said...

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.

vaurice said...

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

Joelsef said...

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.

Arsalan said...

Joel you might have written a detailed blog for this one... I really need your help out this..

I need to use PKI with sharepoint... and I don't know where to start from... any help would be greatly appreciated.


Anonymous said...

You can also use a vendor supported CAC solution such as: