WIF STS, different “kinds” of users, applications and claims

Question

We are currently looking into implementing our own STS (Microsoft WIF) for authenticating our users, and in that process we have come up with a few questions that we haven’t been able to answer.

We have different kinds of users, using different kinds of applications. Each kind of user needs some special types of claims only relevant for that kind of users and the application belonging. Note that we do not control all the clients.

Let’s say that all users are authorized using simple https using username and password (.NET MVC3). A user is uniquely identified by its type, username and password (not username and password alone). So I will need to create an endpoint for each user type, to be able to differentiate between them. When a user authorize, I’ll issue a token containing a claim representing the user type. Is there an easier way for doing this? Can I avoid an endpoint for each user type (currently there are three)?

My token service can then examine the authorized users’ token and transform the claims, issuing a token containing all the users’ type specific claims. So far so good, except for the multiple endpoints I think?

If I need to have multiple endpoints, should I expose different metadata documents as well, one for each endpoint? Having one big metadata document containing a description of all claims, doesn’t make any sense since there is no application that needs all claims.

Update

Some clarifications.

Certain applications are only used by certain types of users. Not one application can be used by multiple user types.

Depending on what type of application the request is coming from, username and passwords needs to be compared for that user type. There are user stores for each type of application. That is why I need to know what application type the request is coming from. I can't resolve the type by the username and password alone.

Answer 1

Based on your problem description, it sounds like you have three indepent user "repositories" (one for each user type).

So imho this would be a valid scenario for three STS or a STS with multiple endpoints.

Another way to solve this could be to distinguish the user type by the indentifier of the replying party redirecting the user to the sts. This identifier is submitted in the wtrealm parameter.

The processing sequence could look like the following:

1. Get configuration for relying party (wtrealm) from configuration store (I'd suggest a database for your rather complex case)
2. Validate user with username, password and user type (from relying party configuration)
3. Add claims depending on user type or relying party specific configuration.

The datasbase/class structure for this could look similiar to this:

Answer 2

Need some more information to answer:

Are certain applications only used by certain types of users? Or can any user type access any application? If the former, you can configure the STS for that application to pass that user type as a claim. Each application can be configured to have its own subset of claims.

Where is the user type derived from? If from a repository, could you not simply construct a claim for it?

Update:

@Peter's solution should work.

Wrt. the 3 STS vs. 3 endpoints,

Many STS - can use same standard endpoint with different "code-behind". Would still work if you migrated to an out-the box solution . Extra work for certificate renewals.

One STS - custom endpoints won't be able to be migrated. Only one STS to update for certificate renewals.

Metadata - given that it can be generated dynamically, doesn't really matter. Refer Generating Federation Metadata Dynamically.