ADFS : Copy claims rules over

Don't know how many times I've done this.

Deploy to Dev., get everything working, deploy to QAS, support QAS acceptance testing, deploy to Prod., smoke test.

When you have a lot of claims rules to copy over, I found a neat way to do it.

e.g. for a CP.

(Get-AdfsClaimsProviderTrust -Name "My CP").AcceptanceTransformRules | Out-File “C:\path\CPClaimsRules.txt”

And then import the rules to the new CP.

Set-AdfsClaimsProviderTrust -TargetName "My CP" -AcceptanceTransformRulesFile “C:\path\CPClaimsRules.txt” .

I've found that this also avoids the issue where you keep a copy of the rules in e.g. Word and then when you try and paste them into the ADFS wizard, you get all kinds of format errors.

Update: But beware copying groups over.

Enjoy!

Claims : Azman in the new claims-based world

Refer : Windows Authorisation Manager

"AzMan is available for use in the following versions of Windows: Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003, or Windows XP. It is deprecated as of Windows Server 2012 R2 and may be removed in subsequent versions."

"AzMan is a role-based access control (RBAC) framework that provides an administrative tool to manage authorisation policy and a run time that allows applications to perform access checks against that policy. The AzMan administration tool (AzMan.msc) is supplied as a Microsoft Management Console (MMC) snap-in.

Role-based authorisation policy specifies access in terms of user roles that reflect an application's authorisation requirements. Users are assigned to roles based on their job functions and these roles are granted permissions to perform related tasks.

Authorisation policy is managed separately from an application’s code. The application designer defines the set of low-level operations that are considered security sensitive and then defines a set of tasks that map onto those operations. The tasks, but not the operations, are designed to be understandable by administrators and business analysts."

Windows Server 2003 was way before the era of claims-based authentication and no doubt it had a place then.

Imagine a library. There could be two kinds of people; librarians and users. 

Users can browse the catalogue and check in / out books. Librarians can also do those functions plus they can order books. So the list of tasks could be:

Now the steps in ordering a book could be:

So the librarian would first check that there was enough budget, then check that the supplier has stock and then process the order.

There is a hierarchy of Role which has Tasks which has Operations. Each operation has a number.

Now you assign Tasks to Roles and then Operations to Tasks.

Lastly, you then assign users to Roles under "Role Assignments" above.

This is all wrapped up in an Application. As above, in the tree, "Library" is an instance of an application.

You then used .COM objects to get the assignments and you ended up with an array of ints; each element was a binary for the operation of that number e.g. if "Check budget" was numbered one, then the first instance in the array would tell you if the user had permission to perform that operation.

Never having used Azman, I may have some details wrong but they are close enough to illustrate the point.

This is all well and good but how to you migrate this to a modern claims-based world using e.g. ADFS.

ADFS authenticates against Active Directory (AD) and AD does not directly support the above structure.

AD does not have a concept of "application" and I'm ignoring that for the moment as my particular requirement was to migrate an Azman based program that only had one application.

AD does allow a hierarchy of roles (called Groups in AD) e.g. A can be memberOf B can be memberOf C.

The problem is that the groups do not display in a hierarchical manner e.g.

The way this is setup in AD is that:

"Librarian" is a memberOf "Order book" is a memberOf "Check budget".

The user is then a memberOf  "Librarian".

In terms of setting up the claims-based application, there are two ways to go:

• WIF (the older way but still supported)
• OWIN WS-Fed (the newer way)

For WIF, refer:

How To: Build Claims-Aware ASP.NET MVC Web Application Using WIF

where the STS = ADFS.

For OWIN, there is a Azure AD sample:

Integrating a web app with Azure AD using WS-Federation

and then convert to ADFS by using:

Use the OWIN Security Components in ASP.NET to Implement Web Sign On with ADFS.

On the ADFS side, be sure to add an LDAP rule that maps "Token-Groups - Unqualified Names" to "Role".

Using this and by adding the code in the gist to display the claims, my user that has the Librarian Role displays as:

The code can now use the IsInRole construct.

Refer Working with claims-based identities in multi-tenant applications for other ways to look at the claims.

Hopefully, this provides enough of the plumbing to get you across the line during your Azman migration.

Enjoy!

OWIN : WS Federation support

Vittorio blogged on this:

Using Claims in your Web App is Easier with the new OWIN Security Components

There's a good reference to OWIN in the above.

WS-Federation in Microsoft OWIN Components–a quick start

But what the article doesn't show is how to display the claims.

Dominick blogged on this:

Test driving the WS-Federation Authentication Middleware for Katana

Horrible hack below - yeah I know! - I put it in the About page in the HomeController ...

public ActionResult About()
{
     ViewBag.Message = "Your application description page.";

     var ctx = Request.GetOwinContext();

     var user = ctx.Authentication.User;
     var response = ctx.Response;

     response.ContentType = "text/html";

     if (user.Identity.IsAuthenticated)
    {
         ... code as above
    }

Enjoy!

Visual Basic : A VB claims-enabled application

There was a question over at the MSDN forum that intrigued me so I thought I would take a crack at it.

The question was: "Looking at the ADFS sdk I found ClaimsAwareWebsite in C#. Is there an example in VB.net as well?".

Disclaimer - the last time I used VB was many, many moons ago.

Ok - so ADFS is the same, WIF is the same, the .NET Framework is the same so it shouldn't be that difficult - right?

I used VS 2012 with "Identity and Access Tool" added.

Take a look here: How To: Build Claims-Aware ASP.NET Application Using Forms-Based Authentication.

OK so we create a new project but select "Other languages / Visual Basic / Web. Then select "ASP.NET Web Forms Application". You could go MVC - I'm more at home with Forms (Yeah - I know :-) ).

OK, that gives us the base project. Now use the "Identity and Access Tool" to "bind" your application to ADFS or wherever. Many references of the web to do this - it's language agnostic. And remember to add your new application as a RP in ADFS.

When you run up your application, you should be prompted for the logon screen.

Sweet!

Now in Step 2 in the above link, add the html exactly as described to Default.aspx.

Remember F7 / Shift F7 swops between code and designer.

You can convert the C# code-behind in Step 2 to VB using e.g. Convert C# to VB.NET .

My page (for reference) was:

------------------------------

Imports System.Web.UI
Imports System.Security.Claims

Public Class _Default
    Inherits Page

    Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load

        Dim claimsPrincipal As ClaimsPrincipal = TryCast(Page.User, ClaimsPrincipal)

        If claimsPrincipal IsNot Nothing Then
            Me.ClaimsGridView.DataSource = claimsPrincipal.Claims
            Me.ClaimsGridView.DataBind()
        End If

    End Sub
End Class

---------------------------

After you have been redirected to the home page after logging in, you should see a table that includes the Issuer, OriginalIssuer, Type, Value, and ValueType claims information about your account.

Enjoy!

Claims : Funny joke

Came across this on Vittorios's excellent blog.

Ref:

The gist of it is:

A passive client enters a shop, and starts looking around.

A salesperson approaches: "Sir, can I help you?"

And the passive client: "Just browsing."

OK - so you need some claims background to get it.

For those who don't have that background - there are two claims profiles for clients viz. active (web services) and passive (browsers).

Enjoy!