WebSSO (single sign on) architectural decision

Sep 22, 2010 at 9:03 PM

I have the same context exactly mentioned in the WebSSO samples (adatum > a-Expense application).

Here are the couple of things in my requirements.
My company has 50 instances of the same application. Each instance(appication) is for each client. For each instance, the login pages look and feel are different.
Every login page has "I need my password" link and some pages have "change my password". It depends on the client customization.

Now, the requirements are:
1. Single Signon.
2. Central Repository of all users (preferrable SQL database).

I choose claim based for this. When i start looking the options, i get different complexities involved in each category. Lets say,

1. Single Signon:
- Is it possible to acheive single sign on with a login page at application level?

2. Central Repository:
- The users in this repository are application based. Some users are employees and remaining are outside users. The company needs to maintain the outside users account, per instance.
We cannot use AD for these people for maintaince perspective. Hence we used SQL store for username and passwords as well as profile information.

3. Issuer:
- I plan to use ADFS as issuer, because customSTS is difficult to build in the production scenarios as of now.
- I read ADFS use custom attribute stores for keeping the profile information but still the users need to associate with AD. Is this true?

Could any body suggest, how can i achieve the WebSSO with my scenarios?

Sep 26, 2010 at 4:39 AM


ADFS can only authenticate users in AD. For other user credential repositories you need to build your own STS or use something like StarterSTS. Your scenario is not 100% clear, when you say “SSO”, what do you mean? SSO between any of the 50 instances? Or between your customer and your app? In either case the answer is “yes”, but the implementation is different.