1) You don t manage the users, not really. You simply take the IClaimsIdentity and use that as the source for your authorization. In my opinion you shouldn t be persisting the claims if you can get away without doing it - the claims should be the source of your user information.

If you want to build upon the claims then take a unique reference from the claims identity, say email address or ppid/signing key OU hash and use that to build your own database, and add your own information.

However your system will never become away of changes in a 3rd party identity metabase - not until a new SAML token is issued and parsed in your application.

2) The claims values are stored nowhere, unless you store them. How you translate that into permissions is up to you - but generally you perform claims transformation to take the external claims and map them to claims internal to your application that you use for permissions. Because claims are coming from external providers you can t change them - you have no connection to those providers.

As you re seeing, federation doesn t necessarily alleviate the need for provisioning. This is an important insight that isn t immediately obvious.

There are multiple ways to address this including:

1. The use of a meta or virtual directory product or
2. By using "JIT provisioning" (AKA "dynamic provisioning" or "on-the-fly provisioning").

Let me explain the latter. This solution, which I also describe on my blog, includes two STSs, an IP-STS and an RP-STS. The first solely authenticates the user; the second is specific to your application and knows what claims are necessary to authorize users of that system. The IP-STS can t issue these application-specific attributes, doing so would require your corporate directory service to be cluttered up with all sorts of application-specific information. Instead, the attributes for users that are maintained in that store and issued by the IP-STS are general in nature and applicable to the user regardless of which application they are using. After authenticating to the IP-STS and getting identity-only claims from it, the token is passed on to the RP-STS. This token service is tightly coupled to your application. It knows what claims users need to access different resources. It can convert the identity-only claims to ones necessary to make this access control decision. So, the RP-STS is a claims transformer that maps identity-related claims into app-specific ones.

How does the RP-STS provision the user? Suppose a new employee is created, as in your example above. When the user accesses your app, he will be bounced to the RP-STS. He won t be logged in there, so he ll be bounced to the IP-STS. The sys admin created an account for him, so he will be able to login, and his browser will bounce him back to the RP-STS. The RP-STS will crack the token, get the user ID (email, PPID, etc.), and see that it doesn t know who the user is. So, the RP-STS will provision the user. It will do this by displaying a Web page, for example. It might collect information that helps it determine the role of that user when accessing the RP. After this, the user will be provisioned (i.e., a record will be created in its database containing claim values for him), and the RP-STS will issue a token specific to your application and redirect him back over there. The application won t know that he was just provisioned; it will just use the claims as it always does. (See why I called it JIT provisioning?)

What if things change after the user was provisioned? OK. Imagine this: the user was created in the directory store ages ago and was provisioned as described above in the RP-STS and he has been using the system happily for a long time. Then there s a policy change that requires users of your application to accept new terms and conditions (T&Cs). The next time the user logs in to the app, he ll be redirected to the RP-STS, to the IP-STS, he ll authenticate, and be bounced back to your RP-STS. At that point, it will notice that the user must accept the new T&Cs, so it will show the user a Web page and get their agreement. Afterward, the RP-STS will issue a security token and redirect him to your app. Your app will, as always, handle the claims and do what it needs to do to authorize access. It won t know and won t care that the user was just "re-provisioned." Alternatively, you can keep changes in sync between the identity store (i.e., your corporate directory) and your RP-STS s claim store using a product such as ILM (or FIM as it s now called). Depending on your system, a product that does back channel synchronization like this might be more appropriate.

BTW, these are not "lame" questions! There are very keen questions that reflect deep thought and intelligent reflection on a very complicated problem. Others that you ll need to answer include:

• How do administrators of your application update its policy (e.g., change the T&Cs)? What UI/API must you create? Is the UI integrated with the one used to manage the IP-STS s policy?
• What sort of trust relationships must exist to make such a system work?
• What if the subject isn t using the passive profile? What if he using the active profile and/or there is no UI?
• How and where are keys located? What permissions are needed to use those keys? How are they reved, distributed, and how are sys admins alerted when they re about to expire?

This stuff is really easy to demo at user group meetings and at conferences, but in reality it is very advanced stuff. If you have other questions, feel free to post them here or get in touch w/ me directly.