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!

Identity : The Microsoft landscape

I get asked a lot about this.

• What is the stack?
• What are the pieces?
• How do they fit together?

There doesn’t seem to be a short, compact overview about this.

So in the spirit of the Github admin who when I ask “Is this feature available and if not when”? replies “Send me a PR”, here goes:

A very short summary – you could write a book on each :-)

In no particular order:

AD DC

Active Directory Domain Controller

The heart of Microsoft on-premises Identity.

It stores users, groups, group policy, printers etc.

Authentication is via Kerberos or NTLM.

In the same domain, IWA can be used if the browser is configured correctly.

AD LDS

Active Directory Lightweight Directory Server - aka ADAM.

Provides ability to store application specific attributes.

Can have many instances on a server, each with a different schema.

Not domain centric.

With ADFS 4.0 (Server 2016) can be used for authentication - ADFS : Authenticating with LDAP.

ADFS

Active Directory Federation Services.

On-premises.

Sits on top of AD. 

Provides WS-Fed / SAML 2.0 / OAuth2 (Server 2016) federation functionality.

Authentication is via WS-Fed or SAML 2 or OAuth.

Has claims rules to manipulate the claims. 

ADFS 4.0 (Server 2016) will support OpenID Connect and OAuth 2.0.

ADFS 4.0 (Server 2016) will authenticate against v3 LDAP or SQL Server.

Has DRS capability to allow devices to be “domain joined”.

Supports IWA.

Can federate with other IDP e.g. OpenAM, Ping Federate, shibboleth, simpleSAMLphp etc.

ADFS 2.0 was a separate download. From then on is a server role and part of the base server.

WAP

Web Application Proxy.

On-premises.

A proxy for ADFS.

Allows ADFS to sit behind a firewall.

Functionality is being added to make it closer to what TMG provided.

Azure AD

Azure Active Directory.

NOT AD in the cloud.

You can think of it as combining AD and ADFS functionality.

Graph based (not LDAP). Supports users and groups only.

Windows 10 devices can be added via “AD Join”.

Has three levels viz. Free / Basic / Premium. Comparison here  – Azure Active Directory editions

Claims collection is hard-coded.

Has outbound SCIM support.

Azure AD Connect

Utility to sync. configured AD attributes from AD to Azure AD. 

This provides Same Sign On. Adding ADFS provides Single Sign On.

Was previously called DirSync.

Azure AD Application Proxy

WAP in the cloud.

Azure AD Domain Services

AD DC in the cloud.

Authentication is via Kerberos or NTLM.

Azure B2C

Business to Consumer.

Allows external user management - registration, SSPR, social logins

Azure B2B

Business to Business

Automated way to provision users so they can authenticate across tenants.

B2B vs. B2C - Comparing capabilities for managing external identities using Azure Active Directory.

Azure Access Panel

Allows end-users to launch their apps and access the self-service features that allow them to manage their apps and group memberships.  

ACS

Access Control Service

The "old" way to connect to social logins - superseded by B2C.

Azure MFA

Multi Factor Authentication.

Easily integrated with Azure applications or on-premises via agent in conjunction with ADFS.

Azure AD Connect Health

Helps monitor and gain insight into on-premises identity infrastructure and the synchronization services.

Monitoring capabilities for key identity components e.g. ADFS, Azure AD Connect, AD DC etc.

Makes the key data points about these components easily accessible, making it easy to get usage and other important insights.

Azure AD Identity Protection 

Helps prevent the use of compromised accounts using industry leading machine learning (ML) based real time detection and automated mitigation.

Helps protect all of the cloud and on-premises applications customers use with Azure AD.

Can auto-remediate by intercepting the request with an adaptive MFA challenge such as an SMS, phone call, push notification or a request for OATH token.

Azure AD PIM

Privileged Identity Management.

Discovery and control of who has administration rights where and when.

Microsoft Advanced Threat Analytics

Detects suspicious user and entry activity, known malicious attacks and security issues.

Cloud App Discovery

Helps IT departments learn which SaaS apps are being used throughout the organization.

Can measure app usage and popularity so that IT can determine which apps will benefit the most from being brought under IT control and being integrated with Azure AD.

Azure SaaS Market Place 

Aka Gallery - Active Directory Marketplace.

Instantly configure popular SaaS cloud applications on Azure AD for SSO and easier user account management.

Wrappers

WIF / OWIN / ADAL : Identity Libraries: Status

Also WIF : Wrappers around protocols  

And OWIN : Differences with WIF

WIF

Windows Identity Foundation.

Provides WS-Fed client protocol support for .NET applications.

Can be passive (browser) or active (WCF).

Older technology.

Capability provided by web.config configuration.

WIF 1.0 (3.5) is a separate download. WIF 4.5 is part of the framework.

OWIN

Open Web Interface for .NET.

Replaces WIF.

Provides WS-Fed / SAML 2.0  / OpenID Connect / OAuth 2.0 client protocol support for .NET applications.

NuGet packages here:

• Microsoft.Owin.Security.WsFederation  
• Microsoft.Owin.Security.OpenIdConnect 
• Kentor.AuthServices.Owin

Capability provided by code.

Can be used for web applications or web API.

.NET Core 1.0 support for OpenID Connect / OAuth 2.0.

Aimed at Azure AD / ADFS with hybrid mode – not a general purpose stack.

ADAL

Active Directory Authentication Library.

OpenID Connect / OAuth 2.0 client protocol support for native devices.

API so underlying protocol could be changed at some future point.

Libraries for JavaScript, Java, PHP etc.

Capability provided by code.

Aimed at Azure AD / ADFS with hybrid mode – not a general purpose stack.

MSAL

Microsoft  Authentication Library - V2 API.

Unified library that helps to develop applications that work with Microsoft Accounts, Azure AD accounts and Azure AD B2C users indifferently – all in a single, streamlined programming model.

Targets the "converged model" i.e. Microsoft Accounts and "Work or School" Accounts combined.

"Successor" to ADAL with the important proviso that it will not work with ADFS and the original Azure AD V1 API.

Microsoft Graph

Was Office 365 Unified API / Graph API.

Exposes multiple APIs from Microsoft cloud services through a single REST API endpoint (https://graph.microsoft.com).

MIM

Microsoft Identity Manager.

Used to be FIM.

Synchronizes identities between directories, databases and applications.

Self-service password, group and certificate management.

Enjoy!

OAuth : Microsoft OWIN (for Identity) and ADAL are not general purpose libraries

I'm seeing a lot of confusion about this.

Microsoft has OWIN client libraries for OpenID Connect / OAuth2.

It also has ADAL - Active Directory Authentication Library (used mainly for native devices).

Both implement the protocols so you would think that you can use these to hook up to any server that implements OpenID Connect / OAuth.

Except that you would be wrong.

OAuth is notorious for incompatibility so you can't really mix and match.

These libraries are aimed at a specific use case i.e. the server is either Azure AD or ADFS.

In addition, the profile is hybrid flow so if your server doesn't implement that you are already out of luck,

Which is not to say that it won't work in some cases.

e.g. IdentityServer 3 does implement the hybrid flow.

Refer : IdentityServer : The WebApp-OpenIDConnect-DotNet Azure AD sample.

Here I show how to use the OWIN library to connect to IdentityServer 3. As you can see, I had to make some alterations.

Enjoy!

OWIN : ASP.NET MVC application with multiple authentication options

There are many questions over at stackoverflow around this.

I have Forms Based Authentication (FBA) but I want to add other providers as well.

In WIF days, this was really difficult to do since WIF added events into the events pipeline.

With the advent of OWIN, this is a whole lot easier.

Assume you have ASP.NET Identity but you also want social (e.g. Facebook)  and WS-Fed and SAMLp. (p for the protocol as opposed to the token)

My starting point was Code! MVC 5 App with Facebook, Twitter, LinkedIn and Google OAuth2 Sign-on (C#).

I wasn't that interested in the social side - my interest was more the enterprise federation and I used Active Directory Federation services (ADFS) v3.0 as my IDP. This supports both WS-Fed and SAML.

The key point in creating the project is to leave "Change Authentication" as "Individual User Accounts". This gives you ASP.NET Identity as a starting point.

You need the following NuGet packages:

Microsoft.Owin.Security.WsFederation

Kentor.AuthServices

Kentor.AuthServices.Owin

The code in Startup.Auth.CS looks like:

// Uncomment the following lines to enable logging in with third party login providers

app.UseMicrosoftAccountAuthentication(
    clientId: "1234",
    clientSecret: "1234");

app.UseTwitterAuthentication(
    consumerKey: "1234",
    consumerSecret: "1234");

app.UseFacebookAuthentication(
    appId: "1234",
    appSecret: "1234");

app.UseGoogleAuthentication(new GoogleOAuth2AuthenticationOptions()
{
    ClientId = "1234",
    ClientSecret = "1234"
});

var adfs = new WsFederationAuthenticationOptions
{
    AuthenticationType = "Federation",
    Caption = "ADFS WS-Fed",
    
    MetadataAddress = "https://xxx/federationmetadata/2007-06/federationmetadata.xml",
    Wtrealm = "urn:owinmultirp"
};

app.UseWsFederationAuthentication(adfs);

var authServicesOptions = new KentorAuthServicesAuthenticationOptions(false)
{
    SPOptions = new SPOptions
    {
        EntityId = new EntityId("https://xxx/OWINMultiAuthWebApplication/saml/")
    },

    AuthenticationType = "KentorAuthServices",
    Caption = "ADFS - SAML2p",
};

Uri metadataURI = new Uri("https://xxx/federationmetadata/2007-06/federationmetadata.xml");

authServicesOptions.IdentityProviders.Add(new IdentityProvider(
    new EntityId("http://xxx/adfs/services/trust"),
    authServicesOptions.SPOptions)
    {
        MetadataUrl = metadataURI,
        LoadMetadata = true,
    });

app.UseKentorAuthServicesAuthentication(authServicesOptions);

You need the following includes:

    using Kentor.AuthServices;
    using Kentor.AuthServices.Owin;
    using System.IdentityModel.Metadata;

So there is just the one application but on the ADFS side we need to configure two RP; one for WS-Fed and one for SAML. Logically, ADFS thinks there are two separate applications.

There is no metadata so ADFS configuration has to be done manually.

ADFS WS-Fed

Set identifier to:

    urn:owinmultirp

Set endpoint to:

    https://xxx/OWINMultiAuthWebApplication/ or whatever for your app.


Set up claims rules as per IdentityServer : ASP.NET MVC application to idsrv3 to ADFS.

ADFS SAMLp

Set identifier to:

    https:/xxx/OWINMultiAuthWebApplication/saml/

Set endpoint as per:

Under the "Advanced" tab, set the "Secure Hash Algorithm" to SHA-1.

Set up claims rules as per IdentityServer : ASP.NET MVC application to idsrv3 to ADFS.

Just to reiterate - you must have a NameID claim for both protocols.

Login screen

Run up the application and you should see something like:

So now you have FBA plus a whole host of other options - all in the same application!

Enjoy!

WIF : Wrappers around protocols

Put together this diagram:

So what does this show:

WIF = WS-Fed
OWIN = WS-Fed, OpenID Connect, OAuth

There is no official Microsoft support for SAML-P (P for protocol). There are open source libraries and commercial stacks - refer : SAML : SAML connectivity / toolkit.

Just to repeat - WIF and OWIN are not protocols - they are wrappers around protocols.

Enjoy!

OWIN : Differences with WIF

This causes a lot of confusion and people keep asking me about this so I thought I would create a tabular comparison.

I'm specifically talking about the NuGet Identity components in OWIN.

OWIN (Identity)	WIF
Fully supported with new features being added	Supported – bugs will be fixed. No new features
WS Fed / SAML / OpenID Connect / OAuth	WS Fed
API’s via code	Invoked via ASP.NET event pipeline
JWT token	XML token
“Change Authentication” with Visual Studio 2013 and 2015	FedUtil with Visual Studio 2010 and “Identity and Access Tool” with Visual Studio 2012

You can think of OWIN as MVC and WIF as Forms. Forms are still supported but all the new whizzy features and all the code samples relate to MVC.

It's important to note the neither OWIN nor WIF are protocols - they are the wrappers around the protocols. The protocols underneath both are identical.

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!