In previous articles we’ve looked at inter-op scenarios with AD FS using gateway solutions such as Juniper SA, Microsoft Forefront UAG 2010 and access management platforms such as OpenAM.  In this post,  we’ll look at using AD FS 2.x with a Windows Identity Federation (WIF)-based Security Token Service (STS) from PointSharp (www.pointsharp.com). This provides us with a broader authentication platform than AD FS from which to make access control decisions.

In a default configuration, AD FS 2.0 makes use of the local Active Directory as an authentication service. As administrators, we may also wish to further extend authentication options available to AD FS.  A number of mechanisms are available, allowing us to hook into third-party authentication services.

1. via plug-ins/agents exposed through IIS, either on the AD FS Proxy/Farm to connect to other authentication providers;
2. customization/ coding sign-in pages to connect directly to authentication providers via web services  or other custom methods;
3. through a federation trust to another provider, e.g. an IP-STS/IdP. 

Option 1 is the traditional access management method, using non-federated agents/filters to wrap around IIS. This approach is often independent of AD FS. Option 2 involves customizing the logon process within AD FS, e.g. customizing forms-sign-in pages to hook into back-end web services APIs that the third-party authentication service may provide.  Option 3 is the claims provider route using the federation trust model. PointSharp cater for all three solutions. However, I’ll concentrate on Option 3, using their Security Token service (STS) as a strong/two-factor authentication provider .

To highlight a working scenario, let’s set out some basic requirements:

• External users, including corporate users, must connect through the third-party STS using  various authentication types, according to the desired requirements:
  • Two-factor authentication (hardware token, soft token or SMS)
  • An alternate password credential store (non-AD)
  • Credentials from the Corporate directory (e.g. AD)
• Internal users, connected to the corporate LAN, should be able to connect to relying parties using their Windows logon credentials (Kerberos/NTLM).
• Applications must support SAML or WS-Federation in an external facing scenario and IWA (Kerberos/NTLM) for internal users.
• The solution should support claims-based access control to the federated web application according to the desired authentication method

The PointSharp Identity Federation component (STS) is a .NET / Windows Identity Federation (WIF) application. It services authentication requests by connecting to a core-access management application via web services.

In logon flow terms, an abridged view of the process is:

1. The external User connects to Relying Party Web Application
2. Browser redirect to AD FS Proxy. AD FS local authentication types are disabled. A claims provider  is defined and the authentication request is passed to this.
3. Browser redirect to PointSharp Identity Federation STS. User logs on. Policy-based access control and claims processing is performed. SAML token is issued.
4. Browser redirect to AD FS (RP-STS). Perform claims processing on Claims Provider and Relying Party.
5. Browser redirect to Relying Party for authorization and access to application.

Users connect to  the PointSharp Identity Federation claims provider (configured) via AD FS, to provide two-factor authentication for external access scenarios.  In order to bypass the (in-built) AD claims provider for AD FS external access, whilst continuing to provide a Windows SSO experience to corporate users, we make a  couple of configuration changes in AD FS proxy and farm nodes:

• Disable all local authentication types on the AD FS Proxy to pass authentication requests to the PointSharp STS. This is done to bypass home realm discovery (HRD) mechanisms and remove the proxy as an authentication layer. We do this by removing the forms, basic and X509 authentication types within the web.config of the AD FS Proxy in the microsoft.identityServer.web section:

  <localAuthenticationTypes>
  </localAuthenticationTypes>

• On the local AD FS farm we adjust settings to ensure that the default Active Directory claims provider, not the PointSharp claims provider, is used for authentication of users connecting via the internal/corporate network.  We do so by customizing the homerealmdiscovery.aspx.cs on the AD FS farm to ensure that the AD claims provider is used for Windows logon. Refer to this blog article on how to accomplish this.

With the above changes, all logon requests via the AD FS proxy will now be handled by the PointSharp STS.

Before continuing further, let’s look at how the PointSharp Identity Federation component (STS) and the backend PointSharp authentication services work to support desired authentication types.  To accomplish this, we’ll need to dig a little deeper into how identities are stored/used within the configuration.

Configuration Storage

As with the majority of Access Management (AM) solutions out there, it’s worthwhile pointing out the distinction between a store used for identity (read-only) lookup purposes, such as a user repository,  versus the store the AM solution uses for holding (writing) configuration options concerning user/profile/preferences. Typically, configuration or data storage is represented in a single aggregate store where information about access identities is written. Conversely, user storage(s), may consist of multiple repositories, which we read user information from.  PointSharp uses an LDAP store, e.g. AD LDS, AD or other LDAP v3 compliant servers for configuration/data storage. The store retains information concerning the users profile, the authentication methods used/supported, additional secrets etc. Sensitive information within the store is encrypted or (optionally) the entire storage container itself.

User Storage

In PointSharp lexicon, user storage is used to define an entry point within a repository for basing scoped searches/extractions from. We can then subsequently target items extracted for authentication/authorization processing. User storage may be one or many directories (AD/LDAP) or specific containers (organizational units) within one or many directories.  Optionally, we may then target a desired authentication method against defined user storage types.

With a given user storage, via scoping options and the use of an LDAP filter , we define objects of “interest” in the storage and, at an attribute level, define various attributes, e.g. logon ID, to be used. This could be a security principal such as  sAMAccountName, userPrincipalName or uid, subject to the object class. In the above screenshot, a User Storage called “inetOrgPerson” has been created,  and within this store (AD),  searches have been limited to include object classes of the inetOrgPerson type from given OUs. The (LDAP) search filter in the chosen user storage is:

(&({usernameAttribute}={username})(objectClass=inetOrgPerson)(objectCategory=person))

There’s some latitude here on what we may wish to include/exclude as objects of interest, for logon purposes, abstracted from the logon process normally associated to the native directory. For example, disabled accounts, which might sound bizarre, can also be exposed via user storage. Attributes such as UserAccountControl are available to expose/include in a scoped search within user storage, thereby allowing subsets of users for remote access,  not normally available in a local authentication context to be used. We may wish to make these available purely for external access. In practical terms, imagine that we have a subset of users that we don’t want to be able to interactively logon to AD, from a domain-joined PC, yet should be able to logon externally (only) via our Identity Federation STS. Here’s an example of an LDAP scope that targets disabled users to be defined at a storage level. 

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))

User storages are processed iteratively. We can include a number of user storage types according to access needs and once we’ve defined them, identify the types of authentication we wish to use directly (via the storage) or indirectly through access policy.

Authentication Services

PointSharp, through back-end authentication services, provide authentication types available directly through listeners via web services or RADIUS, according to the access scenario. Since we’re dealing with identity federation here,  this equates to web services. At this point, we can make available a given authentication type to be used in the identity federation process (e.g. SMS) or elect to use a more fine-grained policy-based authentication process. Smart Authentication (SmartAuth) refers to a policy-based / attribute-based access  workflow executed during logon. Through these policies the authentication type to use for a connecting user is determined. This allows for more granular authentication flows to meet requirements. Moreover, this can also be further refined at the (front-end) Identity Federation component (STS) via claims-based access control.

Using the user storage concepts, let’s have a look at two identity federation scenarios. The first is a “basic” approach using the default Active Directory, available as a user store for moderating external access.

Basic Scenario (Single Storage)

In the above setup, we’re “scoping” our storage based around using various OU’s within AD. The first storage uses sAMAccountName for internal users using their Windows logon ID, the second uses userPrincipalName (UPN) for external users. In this example, sAMAccountName is analogous to EmployeeID and userPrincipalName to the emailaddress of the external user. Each respective set of identities live within their own OU’s within Active Directory.

Complex Scenario (Multiple Storage)

Similar to the basic setup, we’re also scoping our user storage at OUs within a given store. In this case we’re also adding additional repositories, such as a Partner/Affiliates store (e.g. Extranet), to pull in their identities for usage in logon scenarios ….

With the user storages defined, we then define individual authentication types within the back-end PointSharp authentication service and expose these as individual listeners, invoked directly by the caller. In our case, this is the PointSharp Identity Federatrion component calling a smart authentication rule. to adopt more fine grained authentication decisions at logon.

In the above policy, I’ve elected to use membership of a Windows group (in user stores) to target required authentication types.  This involves static management of  a group, so it may be less desirable than using something like a UPN or Email address, matched against a particular suffix to offer a more dynamic evaluation.

For example, a dynamic evaluation can be used, as in the above example, to attach an authentication method to users with an @auth360.net UPN suffix to use an OATH token. I’ll cover dynamic evaluation using directed authentication types and responses in a later post.

With PointSharp Identity Federation, we specify the use of a smart authentication rule as the authentication method

Users logging on from a relying party externally are  redirected to the PointSharp STS. (Note: I’ve already setup the PointSharp STS up as a claims provider within AD FS).

Within the PointSharp authentication service, if you recall from the earlier MemberOf smart rule graphic, we’ve identified four authentication types: OATH, SMS, PointSharp Password and AD Password. OATH tokens are event or time-based OTP schemes using hardware, software and SMS-based logon mechanisms. Both support (optional) challenge/response password/OTP combinations from the user repositories and the login process adapts to this according to the rules defined with the PointSharp authentication service.  In addition, the PointSharp Password is an alternate login credential that can be called upon and is used in cases where customers do not wish to employ two-factor authentication, nor expose the AD password to external access. Instead, they wish to use a separate password source, independent of AD, with separate password/lockout policies, that can be used to provide claims-based access via the PointSharp STS to their web applications. Should we also we wish to make AD password-access available as a possible authentication type, this is also included in the example. Remote lockout conventions can also be applied to AD users, independent of the AD password policy, to ensure that remote access lockout does not necessarily incur a AD password lockout, and to prevent Denial of Service (DoS) lockout on a given user.

Within the PointSharp authentication service admin UI, in a storage called AUTH360, four users have been created for testing:

•  oathman is a user using an OATH token (hardware token / soft token)
•  smsboy is a user using an SMS authentication method
•  psidgal is a user using a PointSharp password
•  adkid is a user using an AD password

From within PointSharp Identity Federation (STS ) we can define claims-based access rules to be passed onto AD FS. To accomplish this, we create custom claims rules on the STS that conform to the authentication type we desire. This is then injected in the SAML token and consumed as a claim by AD FS, as the RP-STS, for further processing, and passed on to the RP. For example, the four authentication types defined within the SmartAuth rule are now processed at the STS :

These are passed back via the custom claims definition:

http://schemas.auth360.net/ws/2008/06/identity/claims/access

On AD FS, we create a claims description that conforms to the above description

On the PointSharp Identity Federation claims provider, we pass the above claims as well as any additional claims that we also elect to emit.  On the claims provider pipeline in AD FS, we configure Acceptance Transform rules to pass the Access Type claims and any other rules that the Claims Provider STS has made available:

On the relying party application we define our issuance transform rules.

I’m using SimpleSAMLphp, a SAML 2.0 Service Provider, as my Relying Party. AD FS, as a broker, provides the necessary bridging between the WS-Federation passive STS of PointSharp and, in this case our SAML 2.0 RP. In the “groups” claim we pass an inbound custom customs claims definition that transforms the authentication method http://schemas.auth360.net/ws/2008/06/identity/claims/access and emit this as a  SAML attribute that SimpleSAMLphp can then consume:

c:[Type == http://schemas.auth360.net/ws/2008/06/identity/claims/access] => issue(Type = “groups”, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

I’ve setup up a basic “Hello World” PHP application, which calls the SimpleSAMLphp libraries and then display the processed attributes in the web page. In our example, the access type (and authentication type) is expressed via the groups SAML assertion in array [0] –LOA4-AD. This is a user logging on who is a member of group LOA4-AD (using AD credentials).

Array
(
    [groups] => Array
        (
            [0] => LOA4-AD
            [1] => users
            [2] => members
        )

    [http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn] => Array
        (
            [0] => adkid@auth360.net
        )

)

At the relying party, we’re now at liberty to make authorization decisions based on the incoming claim, according to the strength of the authentication type. I’m using SimpleSAMLphp here as an example, but the same conventions can be applied to other WIF-based RPs/STS such as SharePoint.

In a future post,  I’ll look at more refined policy assessments using access based on dynamic evaluation and SAML authentication contexts such as SAML AuthNContextClassRef and WS-Fed AuthenticationMethod in RP/SP initiated-sign-on scenarios. Meanwhile, I hope you enjoyed the post.