Identity Framework Probable Feature List

Vittorio has just concluded a series of posts where he's sharing a sneak preview of the Identity Framework (Fx for this post). Based on what he's shown and his descriptions, I've put together a little list of some features we can probably expect from the Fx. This is all pre-alpha stuff and the API will probably change, but the core features being shown will probably be similar.

These are a rather concise set notes that I've taken while looking over his code more closely. I created a wiki page to quickly hack up this list. Here's what it looks like now:

• Fx helps you implement a custom STS
  • STS can issue managed cards (see below)
  • Fx provides a base class for your STS, (it's currently called SecurityTokenService)
  • You derive from this base class and supply a "ScopeProvider" implementation which answers (at least) two questions:
    • What type of claims your STS can issue (you have to generate a list of claim URIs that you will be issuing)
      • This is helpful for issuing managed cards, which need to specify which claims an IdP supplies
    • What claims should be issued for a given user request, which consists of:
      • Information about the target relying party (AppliesTo), which is not always known (an auditing STS will know this, for example)
      • The AuthorizationContext for the user requesting the token (this gives you the incoming set of claims from the user)
      • The actual RST if you want to look at it (this is a WS-Trust thing)
      • The issuer's credentials (you need this to generate the claim set)
  • User authentication methods (an STS needs to authenticate the user before issuing a token)
    • Kerberos
    • X509 Certificates
    • SAML from personal cards
    • Username/Password
• Fx helps you expose your STS using WCF
  • Fx supplies a custom ServiceHostFactory (currently called WindowsInformationCardServiceHostFactory)
  • This allows you to create a .SVC file for a WCF endpoint to expose your STS
• Fx supplies an HttpModule for the traditional ASP.NET authentiation pipeline
  • According to Vittorio, this "automates a lot of the validation work in the framework". It's called FederatedAuthenticationModule, which gives a hint as to its function. It probably sets up HttpContext.User like a traditional authn module would. It's probably not specific to building an STS (remember the Fx is also used to build relying parties)
  • There's a custom config section that configures this module. Vittorio uses it to say, "use my SSL cert as my relying party cert". This is probably required in case the client wants to authenticate using a card.
• Issuing managed cards
  • Fx provides a function to generate a managed card, as well as a class that represents it (it's currently called InformationCard)
    • You can specify the default name and image for the card you issue, controlling what the client sees when she installs your card
    • Fx provides an information card serializer: InformationCard<-->XML (this is what the user installs into her identity selector - an XML representation of the card)
• Fx provides a utility to generate a PPID, which is a pretty complicated task!
  • Currently takes three inputs to gen a PPID for the relying party to use:
    • Client's AuthorizationContext
    • The relying party (AppliesTo)
    • Issuer's credentials
• Fx provides some helpers for reading claims from an AuthorizationContext
  • I notice a ClaimsContext class that allows you to write code like I show below, although I'm not sure how it figures out how it deals with multiple ClaimSets.

string email = myClaimsContext[ClaimTypes.Email]

• Fx provides a set of ASP.NET login controls (three right now):
  • FederatedPassiveSignIn (I'm guessing this is for doing traditional ADFS v1 style logons)
  • InformationCard (login control that accepts information cards)
  • SignInStatus (probably similar features to ASP.NET's LoginStatus)
• Fx helps you build relying parties
  • InformationCard login control
    • You can specify whether you want to accept personal or managed cards
    • If you accept managed cards, a wizard will take a card file as input to automatically configure the control (great idea, guys!)
    • Wizard shows claims supported by the managed card, and you can select which ones you want (either optionally or required)
    • There appears to be a SignInMode that you can use to establish a session. I'm guessing that this issues an ASP.NET Forms logon cookie or something equivalent. This is probably one of the things that the HttpModule deals with (reading that cookie and using it to configure HttpContext.User).
    • Here are the control's identity-related events:
      • SecurityTokenReceived
      • SecurityTokenValidated
      • SignedIn
      • SignInError
    • Here's a picture Vittorio shows that shows a number of the properties of the control if you want to try to guess more about what it's going to do: