Active Directory and SSO - anyone with experience on this ?

Question

Hello,

We want to implement SSO functionality in our organization, but we're not really sure what our options are, and what the benefits / disadvantages for the different solutions might be.

-We have multiple old ASP(Active Server Pages) sites which should use SSO
-We have multiple ASP.net web-Applications which should use SSO
-We want Sharepoint to use the SSO -CRM (Biztalk?) integration (Additional information about the user, such as Address, company, etc )

Since we're primarly .net, c#, Microsoft oriented, my first idea was to use Active Directory.
I've also noticed that there is something called ADAM (Active Directory Application Mode), and ADFS (Active Directory Federation Services), but I can't really say I understand when/where these should be used.

Here is a brief overview of the different web-applications
-"My Personal Page" : User log's into an application where they can modify their personal information along with their company-information and their employees. (Asp.Net)
-E-learning application (ASP)
-CMS system for web-publishing (ASP.Net)
-Sharepoint sites

I haven't really been able to find any articles that can tell me "AD is a great choice! , you can use it everywhere", so If anyone has got any experience /feedback to give me on this, it would be really helpful.

Also: How should rights/roles be managed ? Should all access/rights/roles for each application be stored in AD, or should this be stored in the applications themselves.

IE : AD stores the roles:
"Cms" <-allowed to login to the cms system
"Cms.Article.AddAllowed" <-allowed to add article
"Cms.Article.DeleteAllowed" <-allowed to delete article

Or should this information be split up, so that AD holds information about which applications the user is allowed to log into, while the application itself holds information about what the user is allowed to do within the application when logged in

AD rights: "Cms" <-Allowed to login to the cms system

Cms rights:
"Article.AddAllowed" <-allowed to add article
"Article.DeleteAllowed" <-allowed to delete article

So, when the user logs in, they are first authenticated against AD, and if that goes ok, the rights for the Cms application is fetched from a rights-table in the cms system ?

What are my options ? What other solutions other than AD do I have ?

Thank you for any feedback, its much appreciated !

Answer 1

As far as I know, Active Directory is only practical for users within your domain. You would need an administrator to manage all those users and to add new users.

I've been working on a project myself where I wanted users to sign in, just to know their identity. I did not even care about their access rights but just wanted an identity on every visitor, something more reliable than an IP address, cookie, session key or whatever else. So I first asked my administrators if I could use Active Directory for this project. Sure, I could. But the webhost wasn't connected to our company domain so I would end up with only one user. Yeah, my administrator is a bit sarcastic sometimes.

So I started to explore SSO options. OpenID like this site is a good option and you could even implement your own OpenID server and require all visitors to sign on there first. It's a very powerful technique and you have less worries about managing users in your project. (Because the OpenID provider takes care of this.)

However, I ended up using CardSpace instead. :-) With CardSpace, every user can create their own user-token and store it on their own system. To log on, the website just asks for the card and the user just clicks on it. Those cards can be migrated to other systems but tend to be tied to a single computer and user, most of the time. (Although users can share a card!)

Rights and Roles are a different matter than Authentication. People always think they're connected while in reality, these are two different things. First, use OpenID or CardSpace or another authentication technique to verify the identity of the user. It doesn't matter how they're identified, you just need an identifier. Next, you need rights and roles. Roles are basically just user-groups and you can connect an identity to a group. Or to multiple groups. And rights would be linked to roles, not users. But how you're going to divide these roles just depends on the applications. Just remember that someone who is an administrator in your version control system should not be an administrator in your customer database. Roles tend to be application-defined, thus every application could manage their own rights and roles and just needs a way to link these to an identity.

I myself just needed identities so I knew whom to blame when something ended up messed up. Then again, when there's only 5 users, things tend to become quite simple.

Answer 2

We have done something similar in my organization. Here is the overall flow:

• User requests web page
• User is redirect to login screen along with SAML request
• User authenticates against Active Directory
• User is passed back to request web page with SAML response
• User group/rights information is retrieved from database
• If user requests page from another website same process occurs however if the user still has a session or selected the "remember me" feature then user does not have authenticate and gets logged in directly.

We use Sharepoint, but have not setup SSO yet. I believe Sharepoint gets the rights of the user from its own backend database/system. We also have a homegrown system to update user's groups/rights. I know Sharepoint can use web services so you could possible update Sharepoint when using a centralized user management system (of course you'd have to build that). The main thing is finding out where Sharepoint gets its information about the user and how you can tie your existing system to it...

I wouldn't rely on Active Directory to store group/rights information. It a pain to deal with compared to a database and is not flexible. It's fine for authentication and password management you just have to tie the user on Active Directory to your database system.