Shawn Cicoria - CedarLogic : Identity

Identity Claims Encoding for SharePoint

cicorias — Thu, 30 Jun 2011 15:44:13 GMT

Just to remind myself, the list of claim types and their encodings are listed here at the bottom.

http://msdn.microsoft.com/en-us/library/gg481769.aspx

Where for example:

i:0#.w|contoso\scicoria

‘i’ = identity, could be ‘c’ for others

# == SPClaimTypes.UserLogonName

. == Microsoft.IdentityModel.Claims.ClaimValueTypes.String

Table for reference:

Table 1. Claim types encoding

Character	Claim Type
!	SPClaimTypes.IdentityProvider
”	SPClaimTypes.UserIdentifier
#	SPClaimTypes.UserLogonName
$	SPClaimTypes.DistributionListClaimType
%	SPClaimTypes.FarmId
&	SPClaimTypes.ProcessIdentitySID
‘	SPClaimTypes.ProcessIdentityLogonName
(	SPClaimTypes.IsAuthenticated
)	Microsoft.IdentityModel.Claims.ClaimTypes.PrimarySid
*	Microsoft.IdentityModel.Claims.ClaimTypes.PrimaryGroupSid
+	Microsoft.IdentityModel.Claims.ClaimTypes.GroupSid
-	Microsoft.IdentityModel.Claims.ClaimTypes.Role
.	System.IdentityModel.Claims.ClaimTypes.Anonymous
/	System.IdentityModel.Claims.ClaimTypes.Authentication
0	System.IdentityModel.Claims.ClaimTypes.AuthorizationDecision
1	System.IdentityModel.Claims.ClaimTypes.Country
2	System.IdentityModel.Claims.ClaimTypes.DateOfBirth
3	System.IdentityModel.Claims.ClaimTypes.DenyOnlySid
4	System.IdentityModel.Claims.ClaimTypes.Dns
5	System.IdentityModel.Claims.ClaimTypes.Email
6	System.IdentityModel.Claims.ClaimTypes.Gender
7	System.IdentityModel.Claims.ClaimTypes.GivenName
8	System.IdentityModel.Claims.ClaimTypes.Hash
9	System.IdentityModel.Claims.ClaimTypes.HomePhone
<	System.IdentityModel.Claims.ClaimTypes.Locality
=	System.IdentityModel.Claims.ClaimTypes.MobilePhone
>	System.IdentityModel.Claims.ClaimTypes.Name
?	System.IdentityModel.Claims.ClaimTypes.NameIdentifier
@	System.IdentityModel.Claims.ClaimTypes.OtherPhone
[	System.IdentityModel.Claims.ClaimTypes.PostalCode
\	System.IdentityModel.Claims.ClaimTypes.PPID
]	System.IdentityModel.Claims.ClaimTypes.Rsa
^	System.IdentityModel.Claims.ClaimTypes.Sid
_	System.IdentityModel.Claims.ClaimTypes.Spn
`	System.IdentityModel.Claims.ClaimTypes.StateOrProvince
a	System.IdentityModel.Claims.ClaimTypes.StreetAddress
b	System.IdentityModel.Claims.ClaimTypes.Surname
c	System.IdentityModel.Claims.ClaimTypes.System
d	System.IdentityModel.Claims.ClaimTypes.Thumbprint
e	System.IdentityModel.Claims.ClaimTypes.Upn
f	System.IdentityModel.Claims.ClaimTypes.Uri
g	System.IdentityModel.Claims.ClaimTypes.Webpage

Table 2. Claim value types encoding

Character	Claim Type
!	Microsoft.IdentityModel.Claims.ClaimValueTypes.Base64Binary
“	Microsoft.IdentityModel.Claims.ClaimValueTypes.Boolean
#	Microsoft.IdentityModel.Claims.ClaimValueTypes.Date
$	Microsoft.IdentityModel.Claims.ClaimValueTypes.Datetime
%	Microsoft.IdentityModel.Claims.ClaimValueTypes.DaytimeDuration
&	Microsoft.IdentityModel.Claims.ClaimValueTypes.Double
‘	Microsoft.IdentityModel.Claims.ClaimValueTypes.DsaKeyValue
(	Microsoft.IdentityModel.Claims.ClaimValueTypes.HexBinary
)	Microsoft.IdentityModel.Claims.ClaimValueTypes.Integer
*	Microsoft.IdentityModel.Claims.ClaimValueTypes.KeyInfo
+	Microsoft.IdentityModel.Claims.ClaimValueTypes.Rfc822Name
-	Microsoft.IdentityModel.Claims.ClaimValueTypes.RsaKeyValue
.	Microsoft.IdentityModel.Claims.ClaimValueTypes.String
/	Microsoft.IdentityModel.Claims.ClaimValueTypes.Time
0	Microsoft.IdentityModel.Claims.ClaimValueTypes.X500Name
1	Microsoft.IdentityModel.Claims.ClaimValueTypes.YearMonthDuration

HACK: Forcing FBA Token Refresh against SPClaimProvider with No Credential Challenge

cicorias — Wed, 15 Jun 2011 13:00:53 GMT

The approach takes advantage of the SP 2010 OOB Session Token handler and FBA claims provider implementation that during a period of token lifetime, if there is activity during the period of time that can be defined as "EW" in the image in the section "Background" below, that the SPSecurityTokenManager will, with the FBA provider, reissue a Session Token with new SessionToken ValidTo and ValidFrom times without forcing a re-challenge for user credentials (username and password).

Additionally, it takes advantage of the ability to provide an event handler, on the SessionAuthentcationModule (SPSessionAuthenticationModule) to cause a reissue of the token temporarily with an expiry time (ValidTo) that will cause a SPSessionToken cache miss – thus forcing the re-issue by the SPSecurityTokenManager.

General Approach

The following is a contrived example and uses a rudimentary approach for determine how/when to indicate that the token should be "refreshed" This is done by hooking into the WIF Session Authentication Module's (SAM) Event "SessionSecurityTokenReceived".

The approach taken, and shown on the internet in several posts is to subclass the HttpApplication implementation.

The approach I recommend is to leverage the ability of any HttpApplication by ways of built in ability to identify all HttpModules loaded for that ASP.NET application (SP included) and determine if there are Event handlers specified by ways of the Global.asax in the Root of the SP IIS Site. This is handled by the System.Web.HttpApplication.HookupEventHandlersForApplicationAndModules method.

Note: There are alternatives that I've also tested that work – 1 approach is to register a new HttpModule, then in that HttpModule is to register "1" time a handler for the SAM's SessionSecurityTokenReceived event. This requires a method of indicating at the application level that a handler has already been registered.

Scenario Supported

The general scenario is:

User is already logged onto the site with a valid token
At time required to force a Claims refresh, user will click a link or system will determine how to initiate an HttpRequest that will call the logic required for forcing the refresh
System receives request
SessionAuthenticationModule raises event that custom code will handle
1. This is done by HttpRequest inspection – the sample looks for a Url that contains "RefreshToken.aspx" – there are other means to provide a similar approach.
Custom code identifies the SP LogonTokenCacheExpirationWindow
Using LogonTokenCacheExpirationWindow, custom code forces a re-issue of token that has a ValidTo that will fall into the LogonTokenCacheExpirationWindows – eg.

DateTime newValidTo = DateTime.UtcNow.Add(logonWindow);

System (SP Session Cache) determines that the token requires a re-issue
System calls SPSecurityToken Manager – to reissue all claims for user, bypassing the Logon credentials prompt
During the SPSecurityToken manager re-issue any custom SPClaimProvider types loaded are also called – using FBA and SPClaimProvider will make a call to its FillClaimsForEntity inside of the SP STS.
Session continues with new SessionToken using configuration based values for ValidFrom, ValidTo as defined in the SPSecurityTokenConfig.

Sample Code for Event Handler

The sample code uses another class to contain the code; your implementation could just as easily keep this in the global.asax – however, I'm of the belief that the global.asax should be kept as pristine as possible.

The following code is placed in an assembly that is resolvable through normal fusion – that is, it could be a private assembly. I've chosen GAC in the sample project just for the ease of development.

The code below handles the event and just looks for a page (Url) that contains a well-known request string. This could be anything, but ensure that it's not a common page and based upon the application needs, how your logic will determine a need to refresh all claims.

<%@ Assembly Name="Microsoft.SharePoint" %>
<%@ Assembly Name="RefreshClaimsSample, Version=1.0.0.0, Culture=neutral, PublicKeyToken=329ca2a6e4eeb8c6" %>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
<%@ Import Namespace="Microsoft.IdentityModel.Web" %>
<%@ Import Namespace="Microsoft.IdentityModel.Tokens" %>
<%@ Import Namespace="Microsoft.SharePoint.IdentityModel" %>

<script runat="server">
    void SessionAuthentication_SessionSecurityTokenReceived(object sender, SessionSecurityTokenReceivedEventArgs e) 
    {
        RefreshClaimsSample.SampleRefreshClaims.ForceRefreshClaims(sender, e);
    }
</script>

public static void ForceRefreshClaims(object sender, SessionSecurityTokenReceivedEventArgs e)
{
    if (HttpContext.Current.Request.Url.AbsoluteUri.Contains("RefreshClaims.aspx"))
    {
        SessionAuthenticationModule sam = sender as SessionAuthenticationModule;
        var logonWindow = SPSecurityTokenServiceManager.Local.LogonTokenCacheExpirationWindow;

        DateTime newValidTo = DateTime.UtcNow.Add(logonWindow);

        e.SessionToken = sam.CreateSessionSecurityToken(
            e.SessionToken.ClaimsPrincipal,
            e.SessionToken.Context,
            e.SessionToken.ValidFrom,
            newValidTo,
            e.SessionToken.IsPersistent);

        e.ReissueCookie = true;
    }
}

Wiring up Event Handler

In the SP Global.asax provided a method signature that matches the event from the SAM.

The requirements are that the signature is as follows:

void <moduleNameFromConfig>_<eventName> ( eventArgsType )

Where:

moduleNameFromConfig – must match the name attribute from the module as specified in the /system.webServer/modules/add/@name element.
eventName – must match the event name as defined in the HttpModule's public event
eventArgsType – must match the event arguments type that is defined for the event.

Background

In the above diagram, the settings:

TL = FormsTokenLifeTime
EW = LogonTokenCacheExpirationWindow

These settings are obtained and modified via PowerShell under the SPSecurityT0kenServiceConfig set of cmdlets.

For the following samples, assume the following:

TL = 10 Minutes
EW = 4 Minutes

TL – EW = 6 Minutes

Solution Zip

Welcomed Addition to the WIF Family–SAML-P WIF Extension CTP

cicorias — Mon, 16 May 2011 23:11:55 GMT

This is a very nice addition and will make development across the various WebSSO protocols that much easier.

Announcing the WIF Extension for SAML 2.0 Protocol Community Technology Preview! - Claims-Based Identity Blog - Site Home - MSDN Blogs

SAML Request / Response decoding.

cicorias — Sat, 29 Jan 2011 13:59:19 GMT

When you’re working with Web SSO integration, sometimes it’s helpful to be able to decode the tokens that get passed around via the browser from the various participants in the trust – RP, STS, etc.

With SAML tokens, sometimes they’re simply base64 encoded when they’re in the POST body; other times they’re part of the query string, which they end up being base64encoded, deflated, then Url encoded.

I always end up putting together some simple tool that does this for me – so, this is an effort to make this more permanent.

It’s a simple WinForms application that is using NetFx 4.0.

Download

ADFS v2 Rules Language–Great Short Video

cicorias — Fri, 07 Jan 2011 21:33:36 GMT

http://microsoft.com/showcase/en/us/details/b70adae9-a01d-4b09-9fe9-69b041563640

An Introduction to the Claim Rule Language

Watch this video to see Stuart Kwan (Group PM for the Federated Identity product team at Microsoft) introduce the concepts of the Claim Transformation (Rule) Language used in "Geneva" Server Beta 2. Please leave a comment on the TechNet page to let us know what you think (click Windows Server logo to visit the guide). Thank you for watching! – The Federated Identity Documentation Team

Federation Metadata Generation Tool

cicorias — Thu, 19 Aug 2010 05:11:07 GMT

Disclaimer: Use at your own risk – no warranties are granted or implied

If you’ve worked with Windows Identity Foundation (WIF) without the help of ADFS 2.0, you’ll run into situations where you’ll need to potentially generate or regenerate the metadata used for federation.

Additionally, while WIF supports SAML tokens, it doesn’t have support for SAML Passive Requestor protocol (urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST) - you get that with ADFS 2.0.

So, I needed the ability to quickly generate meta-data and regenerate as needed. I created a very simple tool – hacked in a few hours - that uses the meta data serialization support in WIF (MetadataSerializer) to generate the meta data.

So, this tool will generate the following metadata

Download

SAML IdP and SP

IDPSSODescriptor "urn:oasis:names:tc:SAML:2.0:protocol"
SPSSODescriptor "urn:oasis:names:tc:SAML:2.0:protocol"

And WS-Federation

http://docs.oasis-open.org/wsfed/federation/200706

The tool makes use of the PropertyGrid for binding to some types used to generate, and in order to read the certificate private key it needs permissions – if you run elevated, you should have access.

Wildcard Certificates and IIS7

cicorias — Wed, 23 Dec 2009 21:28:47 GMT

Let’s face it, during development, managing all the certificates if you’re doing anything with validating SSL/TLS traffic is a pain.

Now with Windows Identity Foundation (fka Geneva) we really have to get crackin on getting used to managing certificates, setting up SSL sites, etc.

So, here’s great post on setting up IIS7 to use wildcard certificates…

http://blog.mikeobrien.net/PermaLink,guid,12d9628c-a350-4f7b-a573-9d05429b54e8.aspx

This gives you 1 certificate rooted at some common domain (eg. mydev.local) where all sites would be site1.mydev.local, site2.mydev.local, etc. The CN in the certificate ends up being *.mydev.local – just wire up in your hosts file (..\drivers\etc\hosts) and you’re golden…

SharePoint 2010 and Claims Based Awareness

cicorias — Mon, 23 Nov 2009 16:47:00 GMT

The industry it moving towards identity standards, and with the recent release of Windows Identity Foundation (fka Geneva), and the beta of SharePoint 2010, it’s important to take a look at the direction of how identity is being normalized into a “service” within the SharePoint object model.

With SPS 2010, the SPUser object is now a claims identity. Identity management has been normalized to a approach that internally uses an STS that takes all “provider” or external STS identities, then creates a SPUser claims identity. This can have implications for LOB application design. Even Windows identities are presented within SPS as a claims identity after banging against the SP STS for claims transformation.

Venky Veeraraghavan has a great video up on Channel 9 on how WIF was used to create this model within SharePoint and how we get 1) Identities “In”, 2) Identities “within”, and 3) Identities “out” – specifically, when talking to downstream back-end LOB applications, DB, Web Services, etc. These are all things WIF and claims based identity is moving the industry.

This is certainly how we all should be looking at identity management and authentication scenarios.

(Please visit the site to view this media)