Virtual Smart Cards (VSC) and AD FS 2.0

Before I finish the second article on Step-Up Authentication, I thought I’d write something quick about Virtual Smart Cards (VSC), as they also feature in the next post.

While Windows 8 has been taking lots of flak for various UI changes, there are a number of nice new features that have snuck in rather quietly. One of these is support for Virtual Smart Cards (VSC). VSC’s  provide an alternate strong authentication mechanism  that removes the need for a physical smart card reader. They emulate the use of a physical card reader via the use of the Trusted Platform Module (TPM) found in most modern  business-grade computers. The TPM module stores the private key of the virtual smart card. While, it’s not two-factor authentication per se, (the virtual smart card is stored on the same device as the crypto module), it is nonetheless an improvement strength-wise over username/password and software-based digital certificates. We’ll give it the official 1.5x times authentication moniker (1.5FA) Smile.

Private keys are stored in the crypto functionality of the Trusted Platform Module (TPM) of the laptop. The private key is device centric, with the virtual smartcard stored on the same computer. The TPM module needs to be enable on the computer. This can be done manually (woo-hoo!) or via some form of script, or in conjunction with vendor client instrumentation software.

VSCs provide a number of nice features, but they add a little more added complexity in the setup stakes. Given that we’re emulating physical smart card behaviour, we’re going to need a certificate and that means Certificate Services and an enterprise Public Key Infrastructure (PKI).

I’ve used a Windows 2008 R2 CA in this example. On the enterprise certification authority (CA)  we can duplicate the built-in Smartcard Logon template found in certificate services using the V2 Windows Server 2003 compatible template.


With our new template, entitled Virtual Smart Card, on the Request Handling tab set the certificate purpose to Signature and Smart Card Logon and the minimum key size to 2048. On the Cryptography tab set the cryptographic provider to the Microsoft Base Smart Card Crypto Provider.


Give (authenticated) users Enrol permissions on the Security tab of the template and then issue the new certificate template.


We can use the built-in tool TPM Virtual Smart Card Manager (tpmvscmgr) to provision the smart card.

tpmvscmgr.exe  create /name Auth360Test /adminkey random /generate

The generate command formats the TPM virtual smart card so it can be then used to enrol for certificates.

From a LAN or DirectAccess connected PC we can enrol via use the MMC Certificate Users snap-in, using the Request New Certificate option


Select the Virtual Smart Card template.


  During enrolment a PIN needs to be set.


With the VSC enrolled. we can now logout and the virtual smart card should be available for logon.

Click on our enrolled user and then logon with our PIN.


I thought I’d give this a whirl with AD FS. For the purposes of this exercise, to support VSC smart logon,  I changed my AD FS proxy configuration to support client certificate authentication, modifying the local authentication types parameter in the web.config on the AD FS proxy. We’ll cover other logon scenarios using VSCs in the next Step-Up authentication post.


Meanwhile, TLSClient (SSL Client Certificate) is elevated to the top of the list and switched with the default Forms authentication.

Users accessing the AD FS proxy with a VSC now get a prompt to select their certificate


Having highlighted and click my user, I now enter the PIN.


Users not possessing a smart card user certificate will get a 403 error.


The problem with this approach is that it’s a little generic. We’ve simply configured AD FS to authenticate users based on the presence of an X509 certificate.

We could always add our VSC users to a security group and reflect this in an authorization claim in AD FS, Even better we could configure authentication mechanism assurance and add an issuance policy to our virtual smart card template and then link that policy to a security group. Microsoft provide a couple of Powershell scripts to allow this, The Object Identifier (OID) of the certificate authenticating at AD FS needs to correspond to the linked claims rule to the OID in our “Virtual Smart Card Authentication” security group. We’ll look at  this in a future post about Bring Your Own Device (BYOD), Workplace Join and Work Folders, new features in Windows 8.1.

Step-Up Authentication Scenarios with AD FS 2.0 Part I

This post refers to additional logon schemes that can be supported in AD FS by forcing users to re-authenticate or step-up/step-down authentication to federated web applications. It was prompted by a  recent request from a customer :

“We wish to connect a SAML 2.0 Service Provider (SP) to AD FS. For security reasons,  we require our internal users to logon (again) when connecting to this web application. All users connecting through the AD FS proxy should be prohibited access.”

Whether we choose to call this process re-authentication or step-up authentication really depends on the access case.  To meet the requirement, we’ll be breaking single sign-on (SSO) when accessing the web application above by sending parameterised requests from the web application to AD FS, specifying how to handle authentication uniquely for this app.

Some folks may have pre-conceived ideas about what constitutes step-up, perhaps because it is often associated with multi-factor authentication. While the two do complement one another nicely, step-up is not necessarily multi-factor.  Rather, use of step-up as an access mechanism, is governed by the strength of authentication we wish to accrue to access, at a level commensurate with requirements for protecting that resource. We can use weaker (single factor) authentication where this is deemed sufficient or appropriate.  As an example, a customer may employ two-factor authentication on the outside/edge for all users and then elect to use the AD password, as an additional step-up mechanism for corporate users only to gain access to internal resources.  In authentication strength terms, this is step-down authentication, but in functional terms, it’s designed as a step-up method.

I make the above point, because in the examples described here, we have users logging onto their workstations either using weak (username/password) or strong (two-factor) authenticating against other federated web applications with these credentials.  In each case, we plan on forcing users to logon again when they access this particular SAML 2.0 web application to “step-up” security.

This is an internal only access scenario for the enterprise, meaning that users connecting via the AD FS Proxy should be denied access. Since AD FS Rollup 1, we’ve been able to specify Issuance Authorization Rule on the relying party (SAML 2.0 SP) pipeline that allows requests sourced from the AD FS Proxy to be identified and acted on via the claim description:

Accordingly, we’ll create a deny Issuance Authorization Rule on our SAML web application so that users connecting through the proxy will be blocked.

exists([Type == “”]) => issue(Type = “”, Value = “true”);

Sample Scenario

In a default AD FS farm setup, a domain-joined Windows machine internal user connects to the AD FS farm and authenticates via the Integrated Windows Authentication (IWA) handler using Kerberos/NTLM.  To alter this behaviour, for a given application, and force the user to re-authenticate, we must ignore the existing session cookie.

With WS-Federation, we can do this at AD FS, via a smart link, by specifying the wauth parameter: &wauth=urn:oasis:names:tc:SAML:1.0:am:password

For a relying party using the WS-Federation Passive Requester Profile (WS-PRP) we can also specify the request in the query string or within application code also via wauth.

This is a SAML 2.0-based use case though. As a backgrounder, I suggest reading about SAML Authentication Context Classes and Strengths with AD FS. Within the SAML 2.0 protocol, SAML service provider (SP) can emits certain values in the SAML request that ensures that the required authentication method from the SP is honoured by AD FS. From an SAML 2.0 protocol standpoint, this may be accomplished by:

  1. Setting an Authentication Context Class Reference (AuthnContextClassRef) in the requested authentication context from the Service Provider;
  2. Specifying the use of Force Authentication (ForceAuthn) in the request set to a value of true;
  3. Use of a Comparison rule that is set to exact to expressly set the authentication method. Other settings are also possible (which AD FS supports) but are not covered in this post.

Let’s look at the farm-connected conventions mentioned above in a bit more detail.

Authentication Context Class Reference

In Windows SSO logon scenarios, the AD FS integrated handler uses the SAML  AuthnContextClassRef of urn:federation:authentication:windows. On our SAML 2.0 web application, we’ll request a authentication context class reference of urn:oasis:names:tc:SAML:2.0:ac:classes:Password, so that the forms handler (in AD FS) is targeted as the desired authentication handler.

Force Authentication

The specification of ForceAuthn=true in the initial SAML request from the service provider specifies that the Identity Provider (IdP) should force re-authentication of the user, even if they possess a valid session with AD FS.

Comparison Rule

The SAML 2.0 protocol supports the use of a comparison rule to determine the level of precision to be accorded to the authentication request. If none is specified, AD FS will assume that the attribute is set to exact, meaning that authentication should conform exactly to the AuthnContextClassRef request and is passed to the appropriate handler.

Configuring Service Providers

I’ve used two examples here:

  • OpenAM
  • SimpleSAMLphp

I also planned on including Shibboleth, but hosed my configuration in the process, by reverting the wrong Snapshot of my VM during testing.. *cough*… sorry about that Smile 


Using OpenAM as a SAML SP example, we’ll invoke SP-initiated sign-on through the spSSOInit.jsp page.  In the query string we’re specifying the authentication context and the desired force authentication. &ForceAuthn=true&AuthnContextClassRef=urn:oasis:names:tc:SAML:2.0:ac:classes:Password &idpEntityID=

Note: The above syntax is valid but watch out for white spaces in the example above, not to mention your own domain name.  I’ve added spaces to make the text more legible.

AD FS will parse the request based on the emboldened items in the query string and ask the user to re-authenticate via forms sign-in.


In SimpleSAMLphp, we can set the necessary settings in the configuration file authsources.php, specifying the authentication context and force authentication requirement.

‘ForceAuthn’ => TRUE,
‘AuthnContextClassRef’ => ‘urn:oasis:names:tc:SAML:2.0:ac:classes:Password’,

Authentication Options

How we choose to implement our step-up/re-authentication component depends on the question of sufficiency and what is an acceptable method to choose.  For this exercise, this could mean:

  1. re-using the Windows logon identity (re-authenticate);
  2. using an alternate identity from within the same AD forest (step-up);
  3. using an alternate identity residing in a connected forest (step-up);
  4. using an alternate authentication service; a third-party application that provides stronger forms of authentication

Option 1 – Re-Authentication

The  simplest option  sees the the user replaying their AD credentials, logging on again via the AD FS form, before gaining access to the web application. This is clearly not step-up and doesn’t afford any significant additional protection, , but may fulfil compliance/auditing requirements for access.

Advantages Disadvantages
Simple (uses same identity) Re-authentication not step-up authentication (same password policy)
Protects against inadvertent access to the application if the user is already logged on (e.g. where user fails to lock OS)

Security gain is nominal. Requires claims authorization rules on the relying party to differentiate between valid/invalid users.

Option 2 – Step-Up Same Forest (username/password)

Option 2 uses another set of credentials held within the same AD FS forest. Access to the SaaS application is limited to those users using these credentials (i.e. their “step-up” identity) and an authorization rule to supplement this.



Advantages Disadvantages
Authentication is stepped using another identity besides the corporate logon More complex. Requires additional identity to represent users (user management)
Supports use of stronger password policies on the second identity

Security gain is moderate.  Same factor (username / password) for step-up identity

  Less user friendly (extra identity)
  Shared authentication sources between identities (no isolation)

Option 3 – Step-Up Connected Forest (username/password)

A more complex rendition of this using multiple forests with a single AD FS instance (Option 3):image

In the above setup we have an account forest for our corporate users and a resource forest, where the AD FS server lives (with the AD FS application pool account running in the account forest). A one way forest trust between the two exists. In this option, the step-up identities reside in the resource forest.

Advantages Disadvantages
Authentication is stepped using another identity besides the current logon

More complex. Requires additional identity / shadow account represented in the  remote forest  (user management)

Supports use of stronger password policies on the alternate identity

Security gain is moderate. Same factor (username/ password)  for step-up identity

Shadow account can use same sAMAccountName in remote forest Less user friendly (extra identity)
Greater isolation / independence of action from account forest (supports selective authentication) More complex to manage

For Options 2 and 3, we can also provide further refinement by using AD fine-grained password policies to implement a stronger password policy / account lockout policy applicable to our web application, that exceeds the ordinary password policy levels used for for corporate AD users.

In all above cases, we should consider further restraining access by passing custom claims on the relying party, to assist in determining whether the user in question should have access.

From an AD FS standpoint, there are no configuration changes required in the cases described thus far.  You may note, however, that I’ve not yet mentioned IdP-Initiated Sign-On methods. SHAME! Well, there’s a couple of reasons for this, by which I’ll conveniently recuse myself Smile with tongue out 

  1. Firstly, there a nice solution posted on CodePlex, that works similar to the actions described in this post, albeit by customizing the AD FS sign-in pages instead. It allows assigning the use of forms logon logic to relying parties and also covers IdP-Initiated Sign-On and WS-Federation.    Relying parties registered to use the forms logon are registered in AD FS web.config file, thereby bound to the forms handler.
  2. Also, some customers may be unwilling to modify their default AD FS setup because of a fear that it will throw them outside the realms of Microsoft support. However, if you do wish to support IdP-Initiated sign-on scenarios using the methods above (AuthnContextClassRef and ForceAuthn),  then I’m afraid you don’t have much choice as customization of the  code-behind page for  idpinitiatedsignon.aspx.cs is required. Without these changes, sign-on, either via  logintoRP or relaystate  query parameters, will fail as the desired authentication context (AuthnContextClassRef) has not been set and is not passed by the IdP to the service provider. I used the following MSDN article as a reference to customize the  idpinitiatedsignon.aspx.cs and then tested this using logintoRP parameter, with the query string example below. names:tc:SAML:2.0:ac:classes:Password&ForceAuthentication=true

In Part II, we’ll look at step-up options with stronger / multi-factor authentication methods (aka Option 4). See ya!

UAG 2010 and AD FS 2.0 updated articles

Thanks for those folks who notified me that some of the 2010 articles on the blog have become corrupted. The two original posts have been lovingly restored after applying some TLC.

November 4th 2010 posting: AD FS – Inside and Outside

December 3rd 2010 posting: The Triumvirate – UAG 2010SP1, AD FS 2.0 and Kerberos



Claims-based access with AD FS 2.0 and PointSharp Identity Federation

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 ( 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:


  • 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:


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. 


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 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:

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 and emit this as a  SAML attribute that SimpleSAMLphp can then consume:

c:[Type ==] => 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).

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

    [] => Array
            [0] =>


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.

Release Notes for AD FS 2.0 RU3 updated

Working with a customer recently, we ran into problems with RU3 and the sharing of SAML signing certificates between RPs in their test environment. After applying RU3, as mentioned in the previous post, additional manual actions are required. However, it turns out, following a nice long troubleshooting call with those lovely folks at support, that there are is more to this tale:

1. The PostReleaseSchemaChanges.ps1 script applies only to AD FS Windows Internal Database (WID) configurations. The script is provided with the RU3 update under the SQL sub-folder.

2. AD FS SQL database configurations need to run a script locally on a SQL Server node. This file is known as RelaxedRequestSigningCertsv2.sql  and is available via a newly updated article on the support site (KB 2790338) or directly via the following link:

The updated release notes for RU3 can be found here:

Please read, share and alert your fellow AD FS brethren Smile

AD FS 2.0 – Sharing Signing Certificates across RP Trusts

AD FS 2.0 Rollup 3 provides support for the sharing of signing certificates between multiple relying parties. Prior to RU3, each relying party trust, should they elect to use one, required a unique signing certificate and attempts to share signing certificates between RPs would generate the following error:

MSIS7613: The signing certificate of the relying party trust is not unique across all relying party trusts in AD FS 2.0 configuration

So, following the release of RU3, I was fully expectant to see this fix working.   Following various tests and assistance from PSS, it turns out this is an optional “tweak”, rather than one that is activated automatically through deployment of the rollup, i.e. a script needs to be run to activate this capability.  Following the installation of RU3, in the C:\Program Files\Active Directory Federation Services 2.0\SQL folder is a PostReleaseSchemaChanges.ps1 PowerShell script. This needs to be run on the primary AD FS server from an elevated Powershell prompt.  Once this is done, you should find that you can now configure RP trusts with the same signing certificate.

To test this I used two SimpleSAMLphp (SSP) service providers (App1 and App2)  with online metadata endpoints.

Both Relying Parties (RP) are using the same X509 certificate key pair as defined in the authsources.php file.  Creation of the two relying parties was then possible and exchange of metadata possible without AD FS throwing an error.

AD FS 2.0 Rollup 3 (RU3) is out

As of today 13/02, AD FS 2.0 RU3 is out with a number of updates and hotfixes. This is a cumulative update, so fixes and feature in RU1 and RU2 are contained within.

Some of the changes included:

  • Fix for SAML 2.0 ActAs for Relying Parties
  • Improved HSM support (performance) for Token Signing and Encryption certificates
  • Changes to  how signature certificate handling and validation of relying parties is handled

You can apply for the hotfix here:

Some of the above have been pain posts for quite a while now , so more on these after testing…

Exchange 2010 OWA, Claims-based Authentication and AD FS

I was asked recently whether it was possible to use Outlook Web App with AD FS 2.0 for authentication.  I’d toyed with this in the past with Exchange 2010 SP1, but things had changed in the Exchange mechanics (.NET) since then and this had caused problems for me when using the old configuration with later service packs.  I was curious to see how it would work with Exchange 2010 SP3. Fortunately, it’s always nice to find someone who has dug before you and the following article provided a good guide :

Courtesy of a few adjustments to the author’s notes, which I’ll describe here, it shouldn’t be too long before, it’s possible to have OWA up and running using AD FS and claims on a test rig.

Let’s assume the initial steps as described in the article have been followed:

  • a new IIS web site has been created
  • OWA virtual directories have been created in Powerscript
  • FedUtil has been run

We will need to tweak the web.config of the OWA application and you need to watch for case sensitivity issues with the configuration. Equally, the nuances of  FedUtil and how it processes the web.config file can also be a problem. Changes are required in different portions of the file. In the <modules> section of the OWA web.config, the following needs to be add to the header (follow the case exactly):

<modules runAllManagedModulesForAllRequests=”true”>

I also found during the FedUtil processing that the above line would often be rejected, with a complaint about System.WebServer tags.  Should you experience the same issue, try setting the remaining configuration changes without setting the module change above, get FedUtil to accept them and then change the web.config once more, in order for FedUtil to reprocess and accept the value.

Note that you’ll need to add the securityTokenHandlers after the AudienceURI section.

        <add type=”Microsoft.IdentityModel.Tokens.Saml11.Saml11SecurityTokenHandler, Microsoft.IdentityModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35″>
          <samlSecurityTokenRequirement mapToWindows=”true” useWindowsTokenService=”true” />

When creating the Relying Party in AD FS and pointing to the metadata path in the browser, you might it failing. In my case, testing the federation metadata would redirect the browser to AD FS, because the published metadata fell under the /owa virtual path and the control of the federation service handler. Creating a virtual directory that pointed directly to the owa\FederationMetadata folder under the web site rectified this.

You’ll need to specify the /owa path in the browser when accessing the OWA claims website, otherwise you’ll get an error within OWA, something along the lines of:

An unexpected error occurred and your request couldn’t be handled.

Copy error details to clipboard

Show details

I suspect this is down to the requested URL not matching the Relying Party Identifier.

Normally when I finish this posts, there’s always a warning about testing…. in this case, this is particularly so. It looks like this is not an extensively tested solution with the Exchange team and that aspects such as Claims to Windows Token Service (C2WTS), while acceptable in the SharePoint world, have not translated to real-world acceptance with the Exchange platform.

So… TEST, TEST,TEST and Caveat Emptor.

SAML 2.0 IdP-Initiated Sign-On with RelayState in ADFS 2.0

Ýet another riveting title Smile Dispensing with WS-Federation, we’ll move onto looking at SAML 2.0 integration with AD FS, in particular IdP-Initiated sign-on. In the last few posts we’ve looked at how AD FS 2.0 admins can manipulate the use of the whr function to assist in the realm discovery process as part of sign-in to AD FS using WS-Federation. With AD FS 2.0 and SAML 2.0, a long-awaited feature has been support for SAML 2.0 RelayState. With Rollup 2, the AD FS team have come up with the goods. Like whr on the WS-Federation side, the use of RelayState allows us to support IdP-Initiated login from a SAML 2.0 identity provider (IdP).

Before we look at some examples, here’s a few useful tools to aid building and debugging the use of RelayState.

1. The excellent SAML Tracer plugin for Firefox (

2. A relay state generator for AD FS 2.0 to aid us in building the necessary call-back to AD FS. (

3. A URL Encoder/Decoder to validate the syntax used for constructing the Relaystate query string. I used this one..

To get started, there’s a nice article on the Directory Services blog at Microsoft, as a backgrounder to understanding what’s going on via Rollup 2 and RelayState.

Let’s have a look at how these scenarios may pan out. Putting my rudimentary skills in Visio 2013 to the test, here are three examples:


EXAMPLE 1: Remote SAML 2.0 Identity Provider

In the above example, our user needs to connect, via the Internet, to a remote web application that is configured as a SAML 2.0 Service Provider. This service provider is engaged in a federation trust with AD FS. AD FS as a Relying Party Security Token Service (RP-STS) has the SAML 2.0 Identity Provider (IdP), in the home realm of the user, configured as a claims provider (CP).


EXAMPLE 2 : Remote SAML 2.0 Identity Provider and Service Provider

In the above scenario, both the service provider (SP) and the identity provider (IdP) are remote to the organization. This could be a cloud / SaaS application that the RP-STS organization provides access to to both its users and the remote identity provider organization.


EXAMPLE 3 : Remote SAML 2.0 Service Provider

In the above example, the Identity Provider (IdP) and AD FS are part of the same organization.  The IdP could be an Access Management platform such as OpenAM, a remote access gateway such as a Juniper SA, or an Extranet ADFS instance with the AD FS RP-STS acting as a broker.

Access Scenario

Let’s look at some of the pre-requisites on the AD FS side:

1. Install AD FS 2.0 Rollup 2 on all instances where AD FS is involved: proxies, farm members and also third-party organizations if AD FS is installed there.

2. Add the following change to <microsoft.identityServer.web> section of the IIS web.config of all participating AD FS instances, under the /adfs/ls path.

   <useRelayStateForIdpInitiatedSignOn enabled=”true” />

In this example we’ll evaluate ADFS in a SAML 2.0 Identity Provider (IdP) role within a third party Organization, called Fie, and also as a Relying Party Security Token Service (RP-STS) within the resource organization (Foo).  Fie Users may click on a hyperlink or a bookmark that kicks off the logon process with their IdP, and through the use of RelayState, via the parameterized Relying Party Identifiers provided to the IdP and RP-STS ADFS instances, the user is sent to the service provider application.

For our web application and SAML 2.0 SP, I’m going to use cloud provider OneLogin. This will act as an application portal. Once logged on via the IdP, the user is sent to the OneLogin portal thru the RP-STS of Foo. Referring to the diagrams above, this access scenario probably best fits Figure 2. Since the web application belongs to Foo, we’re using an indirect trust involving the Foo ADFS instance as an RP-STS. Fie is a claims provider (CP) to the Foo organization ADFS and the web application is a SAML 2.0 Service Provider (SP) that trusts the ADFS instance as an Identity Provider (IdP).

Here are the service endpoints and relying party identifiers that we need to use to build the appropriate link.

Using the new notation provided in Rollup 2, two relying party identifiers (RPID) are required in order for the relay to the web application to work correctly. The RPID in ADFS terms is the identifier. For a SAML 2.0 SP, this is the Entity ID of the web application. In some scenarios the entity ID may not be sufficient and additional parameters required. Refer to the Microsoft article mentioned earlier on how this may be further encapsulated into the RelayState. I’ve included the URL encoded and decoded syntax below to give you an idea the syntax we’re forming.

Here’s the URL Decoded link, broken into three parts:

  1. &RelayState=RPID=
  2. &RelayState=RPID=

Part 1 is the URL of the Identity Provider, Part 2 the query string and RelayState for the RP-STS, and Part 3 state for the SAML 2.0 SP.

Users logon on at Fie IdP, either through the AD FS proxy using forms-logon, when connecting externally or with their Windows logon ID thru the ADFS farm.  Once we’ve encoded the link, it looks like this:

And we hit the OneLogin portal:


I began the post with a smiley, so I’ll end with one.. nice feature Smile..

AD FS 2.0 Rollup 2 and WHR – We Has Resolution (Part 2)

In the previous post we covered WS-Federation whr changes in AD FS 2.0 Rollup 2.  With this fix in place and enablewhrpersistence set in our web.config,  let’s look at scenarios on how the configuration can be used to manipulate home realm discovery in greater detail. 

Our mythical ‘Foo’ organization consists of an existing AD FS 2.0 proxy/farm setup and two claims providers configured:

  1. default AD provider
  2. third-party claims provider providing strong/two-factor authentication (2FA) to Foo users

Foo has recently engaged in a number of collaboration projects with three other companies: Fee, Fie and Foe. Wishing to further cement these relationships, Foo has elected to setup federation trusts with each of them, and provide access to their local WS-Federation web applications.  The Foo Security Officer, however, has decided that other home realms should not be visible within AD FS in the drop-down box of the home realm discovery page.  All RP-initiated requests via the AD FS proxy must go to their third-party two-factor authentication (2FA) claims provider.  This requirement, however, conflicts with the need to service federated logon for other organizations.

Given the above constraint, we have a number of options:

  • Use an additional farm;
  • Customize the home-realm discovery pages and logon experience on the existing farm to support the desired user experience for third-parties;
  • Customize the relying party(s) to route the whr request;
  • Use out-of-the-box features.

Not being much of a code monkey, let’s look at options out-of-the-box. With the new configuration, there are now five claims providers Foo has to deal with.

  1. Active Directory Claims Provider (0)
  2. 2FA Claims Provider (1)
  3. The Fee Organization Claims Provider (2)
  4. The Fie Organization Claims Provider (3)
  5. The Foe Organization Claims Provider (4)

Foo AD FS Proxy Customization

For external access, as per security requirements, only the 2FA claims provider should be visible directly from the proxy, making it the default selection for external access. This is arranged  on the AD FS Proxy side by modifying the homerealmdiscovery.aspx.cs file and then removing the claims providers, as eligible entries, from the Page_Init section of the file. We need to process their removal in reverse order, starting with the last claims provider in the list, then the next to last etc., until we have the desired CP . For example, with five claims providers, the following changes are made:


We’re left with claims provider (1) in this example, the 2FA provider. Note the order may vary according to order created.

Once this has been done, the following line also needs to be added :

SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

This will default logon to the 2FA provider claims provider at the AD FS proxy. 

Foo AD FS Farm Customization

For users with managed clients/corporate PCs in the Foo organization, we need to ensure that realm discovery is also handled in the right manner. 2FA is not a requirement internally, but SSO via the Windows logon token is desirable. While we covered this in a previous post, it’s worth repeating here. On the AD FS Farm, the Page_Init section of the homerealmdiscovery.aspx.cs file needs to be set so that it defaults realm selection to the Active Directory claims provider.

SelectHomeRealm ( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

If this is not set, then all claims providers are visible on the home realm discovery page, something which we don’t want to trouble internal users with on the corporate network. 

With persistence enabled on the home realm discovery page (of the Proxy), a user may fall foul of cookie handling if he/she works from home, logs on and then returns to work, only to discover that the cookie has persisted and the browser points them to the 2FA provider.  We can temper the cookie behaviour of the AD FS proxy by disabling persistence within the web.config on the AD FS farm.

<persistIdentityProviderInformation enabled=”false”/>

Connecting Organizations

For users from other organizations connecting to Foo; e.g. Fee, Fie and Foe, we rely on smart links from AD FS instances in these organizations to route the request and for the home realm cookie to be written correctly via the whr parameter. Note that these claims providers could also use non-Microsoft identity providers/issuers, such as a Juniper SA (SAML) or a PointSharp WS-Federation Identity Provider, such as . 

While useful, smartlinks are not without limitations.  Firstly, we’re assuming the relying party is a WS-Federation based web application.  If the relying party is a SAML 2.0 web application then the WS-this approach is not applicable. The solution described here does not work and a different type of customization is required. More on this in a future post. The second limitation concerns users from claims provider realms bookmarking Foo (federated) web applications. Should the home realm cookie expire, accessing a bookmarked RP web application will fail as it routes them to the 2FA provider. While Rollup 2 made persistence via whr possible, we need to workaround this shortcoming. We could set the lifetimeInDays value of the cookie in the homerealmdiscovery.aspx.cs of the Foo Proxy to such a high value that this would not be an issue.  Sadly, this is not entirely foolproof either. Browser configuration for users in partner organizations, e.g. Delete browsing history on exit,  may influence whether the realm cookies are retained or not.  Whatever setting is opted for by the resource organization (Foo) is something that will need to be communicated with partner organizations.

AD FS 2.0 Rollup 2 and WHR – We Has Resolution!

Delving further into the dark arts of AD FS 2.0 in this post, we look at whr and home realm discovery, together with smart links,  and how these assist in claims provider trusts with other organizations (particularly in light of changes in Rollup 2).

Developing a strategy for Home-Realm Discovery (HRD) is an essential part of any AD FS configuration. In scenarios where an organization has multiple claims provider trusts, things tends to get a bit complicated,,,

ADFS 2.0 Rollup 2 contains a fix relating to use of the whr parameter. The Release Notes explain the issue to date:

The whr parameter that is specified by an application for a home realm discovery scenario overwrites the previously set home realm discovery cookie. This causes a user to be redirected to a different identity provider that the user cannot use to sign in when the user uses a different application.

You may recall that, in previous posts, we looked at ways in customizing the use of realm discovery and claims provider selection via the homerealmdiscovery.aspx.cs page. This was done to suppress claims provider selection to make life easier for our users.  The link talks about such access scenarios.

In the above scenarios we looked at defaulting the AD FS Proxy to another provider (a strong authentication provider) and removing realm selection options by the use of the Select Home Realm parameter. In the back-end we set the default claims provider to be AD, thereby sending all authentication requests to Active Directory. This conveniently avoided home realm discovery by hard-coding the selection of the claims providers to the strong authentication claims provider on the AD FS Proxy and the built-in AD provider on the back end.

When add additional claims providers to the mix, e.g. federation capable partner organizations, we hit the issue described in the release notes, because suppression of the home realm selection and the whr limitation means that remote users are sent to the strong authentication provider. 

To the rescue, the release notes explain:

The Update Rollup 2 for AD FS 2.0 update resolves this issue by not overwriting data in the home realm cookie when home realm information is provided through the whr parameter. To set a home realm cookie that contains the whr parameter when the home realm cookie is not present, set the following configuration in the Web.config file:

<persistIdentityProviderInformation enabled=”true” lifetimeInDays=”30″ enablewhrPersistence=”true”/>

When the setting is configured, AD FS 2.0 will create a home realm cookie with the identity provider that is specified in the whr parameter when the whr request is sent, and when there is no home realm cookie. The whr request does not overwrite the cookie when there is already an existing home realm cookie.

In other words, AD FS 2.0 creates a home realm cookie for the identity provider/issuer specified, if one doesn’t already exist and persists that cookie according to the lifetime specified in the values set in web.config

For remote access scenarios with partner organizations and trusted claims providers, this provides a nice way to govern access through the use of IdP-Initiated smart links. For the resource partner organization, we continue to allow our logon pages being served up for our users, whilst allowing us to keep a strong authentication logon for our AD FS proxy and default AD provider in the back-end. Additionally, the practical benefits of this fix are more apparent in IdP-Initiated sign-on scenarios, when there are  multiple web applications in the resource organization that need to be surfaced.

For example, we have a portal application in Organization A. The application provides an IdP Initiated smart link on its web page to an Intranet SharePoint 2010 application located at Organization B. To complicate matters, other applications are exposed through nested links in the Intranet web application, linking to other claims-aware applications such as SharePoint Teamsites and Organization B wants to make these applications available also to Organization A.

From an access point-of-view, prior to Rollup 2, this became very messy very quickly.  A User in Organization A logs on to the SharePoint Intranet web application via  an IdP-initated smart link and later in their session try to access the Teamsites web application. The local (resource) AD FS instance will serve up the home realm discovery page and the claims provider drop-down, because the whr parameter does not persist the home realm cookie.  If we’ve also suppressed the claims provider in the selection page (on the proxy), by customizing the homerealmdiscovery.aspx.cs, we have a double whammy as the user can no longer access their home realm .. OOPS!

As of Rollup 2, this behaviour is contained because the home realm selection via the whr in the IdP-initated smart link now stores the home realm cookie.

Let’s walk through a use case:


A user in Organization A ( clicks on a smart link on their portal ( to access an claims-aware SharePoint Intranet web application in Organization B. This link  calls the AD FS instance in Organization B ( with the whr parameter set to the ADFS instance of Org A ( and the wtrealm parameter set to the Intranet web application (

Here’s the smart link in Organization A:

When clicking on the link, the user is redirected by the Organization B AD FS instance to Organization A, where the user authenticates against their local Active Directory with their Windows token or logon via the AD FS proxy sign-in page (if they’re on the Internet). Following successful authentication, the client is sent back to the Organization B STS, claims are processed, before being redirected to the relying party (SharePoint) for further evaluation. Assuming our claims are set correctly, the user gains access to the SharePoint Intranet web application and because we are running Rollup 2 with the change in web.config,  a home realm cookie based on the whr reference is stored.

Now let’s imagine that our user, surfing around on the Organization B Intranet web site,   clicks on a link on the Intranet web application which calls another onsite relying party , Teamsites. The Teamsites web application is located at the (example) URL of This is a different relying party and so the access and claims  of the federated identity again need to be validated. Because the home realm cookie this time has been written correctly (through successful logon via the Intranet application), a relying party (RP-initiated) sign-on is now possible and the user can, assuming they are authorized, gain access to the Teamsites web application successfully without being scuppered by home realm discovery.

Prior to Rollup 2, the user would have been faced with the Home Realm Discovery selection screen, or, if we’d suppressed the claims provider, to the wrong home realm.


With the enablewhrPersistence=”true” value set in web.config, courtesy of Rollup 2, the  home realm discovery page is now bypassed because the home realm details are stored in the cookie stored during the successful IdP-initated sign-on and RP-initiated sign-on now works.


ADFS – SAML 2.0 Identity Provider and SaaS Service Providers

Under ADFS 2.0, Microsoft support the SAML 2.0 IdP Lite and SP Lite modes described in the Liberty Alliance/Kanatara Initiative interop program and eGov Profile 1.5, covering the essentials for identity federation.  From a configuration perspective, we often come across issues in the federation setup phase that can trip up ADFS and the administrator. Sometimes this is the case when dealing with SaaS applications, where there may be minimal customization possible from the vendor standpoint, with the application living in a multi-tenant environment. Tweaking “their side” may not be possible or something that the vendor is comfortable or capable of doing.

In this post, we’ll look at some of the integration issues one may experience when integrating ADFS as an IdP with SAML 2.0 SP web applications using the SAML 2.0 POST profile. There are a number of useful debugging aids/tools that can assist in the troubleshooting process.

All of the above are useful to lean on and gather problem-solving information during troubleshooting.

Scenarios covered here are using ADFS 2.0 as an Identity Provider (IdP).

ADFS Configuration

There are some common gotchas when configuring the relying party in ADFS in the UI.

Issuer / Identifier

Based on the SAML specs, the <samlp:AuthnRequest> must include a <saml:Issuer> including the EntityID of the Service Provider. If you’re creating the relying party manually, double check that the relying party identifier you specify matches that of the EntityID specified in the XML file provided by the Service Provider.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<EntityDescriptor entityID= xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

If there’s a mismatch then this may trigger an error:

Exception details:
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier ‘’ could not be located.

In the above example, the expected identifier is was mis-configured in the UI by yours truly with an identifier of .. back into the UI to correct…



Certificates deserve an entirely separate post, but not today Smile…… a few caveats though.. for token signing, the requirement for signing of SAML sign-in requests by the RP is optional. Should you wish to enforce this it is configurable via Powershell … besides importing the requisite token signing certificates and handling the lifecycle management of your certificates in a diligent fashion, bear in mind that if you also want to employ encryption (and possess an encryption certificate) ADFS will sign assertions by default. Moreover, it will use AES-256 for encryption. This can cause issues with service providers that support weaker algorithms. If you experience this issue, then you may be forced to disable claims encryption for that relying party. This can be accomplished through Powershell (set-ADFSRelyingPartyTrust). I’ve not found a way to tweak this in a more refined fashion than on/off…

Another problem to be wary of is certificate revocation checking… if a Certifcate  Distribution Point (CDP) is referenced in the signing or encryption certificate of one of the federation partners, then the corresponding party must be able to reach that CDP in order to determine the validity of the certificate. This can be problematic, for example, if your security policy blocks connections from servers to the Internet or if the counterpart does not publish it over the Internet. 

Secure Hash Algorithm

A common problem when connecting to relying parties, ADFS defaults to the more secure but less well known hash algorithm of SHA-256. SHA-1 is more widely used with the majority of  cryptographic libraries. If you’re getting an error such as this:

SAML request is not signed with expected signature algorithm. SAML request is signed with signature algorithm . Expected signature algorithm is

Flip the secure hash algorithm over to SHA-1 on the Advanced tab in the Relying Party trust to fix this.

SAML Integration

Contained within are some SAML integration issues experienced that I wanted to share.

NameIDPolicy Format URIs

Normally contained with an authentication request is the NameID Policy and format attribute(s). There are numerous ways in which intended or unintended settings can trip up the federation process. When troubleshooting, start with the ADFS event logs as these can be quite revealing.

Here are a couple of sample problem cases.


PROBLEM: A federation trust has been setup between Organization A and SaaS Provider B. Users attempt to access their SaaS application via SP-initiated logon. After logging on an at ADFS, the SAML redirect returns them to the web application where it fails with a generic HTTP 500 error at the web application.

The SAML authentication request had a NameID Policy that could not be satisfied.
Name identifier format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Exception details: 
MSIS1000: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient SPNameQualifier: . Actual NameID properties: Format: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified, NameQualifier:  SPNameQualifier: , SPProvidedId: .

Looking at the ADFS logs we find MSIS1000 errors. As the above message indicates, the requester is expecting a format of Transient, but we’re sending a format of Unspecified.  Oops…

SOLUTION: The Event Log message also reported that “Use the AD FS 2.0 Management snap-in to configure the configuration that emits the required name identifier.” In other words, fix the identifier… our mismatched name identifier in this case can be fixed by creating a transform Rule and setting the NameID format to what the relying party expects -  transient. In the example below, we take the incoming claim of Common Name and pass it to the Name Identifier in Transient form.

c:[Type == ""]
=> issue(Type = "", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[""] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient");

Note that the use of transient and persistent formats in identifiers are intended to provide privacy-preserving pseudonyms to protect the identity of the subject. Persistent assumes that the identifier assigned to the identity remains the same each time the user logs on, whereas Transient properties are per session. If you want to create opaque identifiers during logon, I suggest reading the following useful article:

In my case, the application I was using involved personalization and rendered this approach unsuitable. Also, by transforming Common Name into Transient on the claims pipeline, we are also circumventing the privacy-preserving methods that Persistent/Transient were intended for, as the name is no longer obfuscated. Token encryption can be used to overcome this, but that brings its own caveats.


PROBLEM: A federation trust has been setup between Organization A and SaaS Provider B. Users are attempting to access the SaaS application via an SP-initiated logon process. After logging on an at ADFS, the SAML redirect sends them to the web application where it fails with a generic HTTP 500 error at the web application.

The SAML authentication request had a NameID Policy that could not be satisfied.
Name identifier format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient
Exception details:
MSIS1000: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient SPNameQualifier: Actual NameID properties: Format: urn:oasis:names:tc:SAML:2.0:nameid-format:transient, NameQualifier:  SPNameQualifier: , SPProvidedId: .

Looking at the ADFS logs we see MSIS1000 errors. In this scenario, ADFS is not providing an expected NameQualifier and SPNameQualifier to the Service Provider in the SAML Response.


Via a claims rule we can insert the relevant information that the service provider is seeking to satisfy the authentication request.

c:[Type == ""] => issue(Type = "",
Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[""]
= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties[""] = "",
Properties[""] = "");

Authentication Context

Authentication contexts allow the service provider (SP) to augment in the assertion, the type  and strength of authentication desired. To increase the chance of (successful) interoperability the <samlp:AuthnRequest> should not include a <samlp:RequestedAuthnContext> element. This recommendation bears out in testing with ADFS. The support for different authentication context classes vary and the semantics often interpreted differently. When processing a SAML authentication request, the interpretation of the relative strengths of the different authentication context classes is up to the responder and AD FS 2.0, by default, interprets the relative strength of these different authentication context classes in its own order. By default, this is:


When the service provider is requesting this information, you may find that out-of-the-box it doesn’t work… let’s have a look at some examples …


PROBLEM : A federation trust has been setup between Organization A and SaaS Provider B. Users are able to logon to the SaaS application via the ADFS Proxy from home or remotely using form-based logon. When they logon internally,  via the ADFS farm, the same users are not able to do so and get an HTTP error. 

<samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="minimum"><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></samlp:RequestedAuthnContext>

In the above SAML authentication request, the Service Provider (SP) is specifying that the expected authentication context  from ADFS is  urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport. Users doing an integrated windows logon are not emitting this authentication context and instead they transmit urn:federation:authentication:windows in the authentication context to the RP and it may trigger an exception.


There are a couple of ways to tackle this problem:

(a) the service provider may be able to submit the additional authentication context for Windows authentication (urn:federation:authentication:windows) to their configuration.  
(b) if the service provider does not support this change, we can provide the appropriate value in the relying party response by checking for the presence of NameID and then parsing urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport in the response. For example:
exists([Type == ""]) => issue(Type = "", Value = "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport");


PROBLEM: A federation trust has been setup between Organization A and SaaS Provider B. Domain-joined users expecting single sign-on through ADFS are being presented with the forms logon handler when accessing the SaaS application internally. They then have to manually enter their credentials per session.

<samlp:NameIDPolicy  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" AllowCreate="true"></samlp:NameIDPolicy>
<samlp:RequestedAuthnContext xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact"><saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></samlp:RequestedAuthnContext> </samlp:AuthnRequest>

The service provider was, by specifying a comparison of "exact", forcing the authentication context for all users to be set to PasswordProtectedTransport, inadvertently telling ADFS to downgrade authentication for domain-joined clients to forms logon, thus defeating/breaking SSO for internal clients.

SOLUTION: Ensure that the SP sets the RequestedAuthnContext comparison to minimum.


That’s it for the moment…… I’ll add to this when new scenarios crop up or via  input from other contributors..

Automated Update of Federation Metadata with Office 365

Another Powershell script from the ADFS team that makes life a little easier.

When the token signing certificate of your home AD FS organization expires, then federation metadata between AD FS and Office 365 falls out of synch. Equally, when changes are made on the Office 365 that require updating the metadata, a similar issue arises. The  script provide by the AD FS team checks the that federation metadata is validated regularly and any changes replicated between the two federating parties.


What does the script do? It calls the Update-MSOLFederatedDomain cmdlet and updates the settings in both the Active Directory Federation Services 2.0 server and Office 365. It also adds an item on the task scheduler queue:


It’s worth bearing in mind that the password policy that is being applied to your organization (Enterprise or Standard O365) will render the script unusable in the event of a password change on either the O365 side with the account you specify and the Domain side with the user account used to initiate the scheduled task. It is possible to create service accounts to do this on both sides. However, I’d consider the security consequences of such a change before automatically doing so. This can be done on the O365 side with an Office 365 standard account via the Set-MSOLUser cmdlet. For example,

Set-MSOLUser –identity –PasswordNeverExpires $true –StrongPasswordRequired $true

The account could also technically be a federated account, but I don’t believe that’s a good idea. In the event that the trust is broken, then a federated account won’t be able to connect to MSOL to update the federated domain information Smile 

On the AD side, a more suitable compromise may be found by using a least privilege account for the task service account.

TMG 2010 and Office 365 Single Sign Out with AD FS 2.0

A while back (June 2011), I wrote a post on how to implement TMG, Single Sign-On (SSO) and strong authentication with Office 365. It was, as it turns out, an incomplete story. 

Tristan Watkins has written an excellent article on how to implement single sign-out using TMG with Office 365 and ADFS 2.0. It goes into great detail about issues with sign-out from non-federated proxies with ADFS/O365 and explains the various nuances associated with Office 365 sign-in…. you can read this article here:

AD FS 2.0 Claims Workflow with Issuers and Identity Providers

If you’re working with an AD FS farm with multiple claims providers, you may find it advantageous to generate “identifier” claims from those providers, so that in subsequent workflow in the claims pipeline, this can be used to build authorization logic around them and claims issued.

For example, let’s say we have Identity Providers FOO and BAR, using e-mail address as the inbound assertion/claim.

In the claims provider settings for each we’re going to validate the inbound request from the Foo IdP and the Bar IdP, based on the Issuer (Entity ID) and then insert a value into a claims description called

Foo Issuer / IdP

c:[Type == "", Issuer == "https://foo.mydomain/com/idp"]
=> issue(Type =, Value = "Foo IdP");

Bar Issuer / IdP

c:[Type == "", Issuer == "https://bar.theirdomain/com/idp"]
=> issue(Type =, Value = "Bar IdP");

If we then wish to insert further values  from an attribute store or  modify the claim later on , then this allows us to do so by calling upon the previously defined description, validating the value against our expected result and then issuing a new claim according to our requirements.

AD FS 2.0 and Multiple Claims Providers

Carrying on from where we left off in the last post, let’s look at some sample scenarios for implementing mixed authentication scenarios using a combination of AD FS and third-party identity providers. As usual, the assumption is that some sort of split-DNS in the federation service namespace is available.

In this example, AD FS will act as a hybrid Security Token Service (STS).  In addition to the out-of-the-box AD FS claims provider (IP-STS) role,  AD FS must act as a Relying Party Security Token Service (RP-STS) for two claims providers; the first where it trusts a SAML capable  two-factor authentication claims provider,  the second where it trusts a gateway portal that provides IdP-initiated sign-on.


In the above diagram, note the use of split DNS to differentiate between user experience inside and outside of the organization; namely, internal resolution of  the AD FS federation services endpoint points to the AD FS farm, whilst externally resolving to the AD FS Proxy(s).

Here are the sign-on use cases:

External SP-initiated Sign-On

  • Authentication: Two-Factor Authentication (OTP)
  • Customization: AD FS Proxy Configuration

A1  – Client accesses Web Application
A2  – Client is redirected to AD FS RP-STS for processing (A2-1)
A3  – Client is redirected to 2FA Provider for logon.
A4  – Following successful authentication at 2FA, client SAML assertion is passed to AD DS RP-STS for claims processing.
A5  – Client is redirected to Web Application (RP)

External IdP-initiated Sign-On

  • Authentication: (a) X509 Certificate + Username/Password (b) Grid Authentication
  • Customization: None (use of Smartlinks)

B1  – Client accesses IdP-capable Portal
B2  – From the portal,  client selects bookmarked Web Application (Smart Link)
B3  – Client is redirected to IdP to determine whether user has valid logon token for SSO
B4  – Client is redirected to AD FS RP-STS for claims processing
B5  – Client is redirected to web application (RP)

Internal RP/SP-initiated Sign-On

  • Authentication : Integrated Windows Authentication (Kerberos/NTLM)
  • Customization : AD FS Farm Configuration

C1  – Client accesses web application
C2  – Client is redirected to local AD FS IP-STS for processing. AD is set as default realm via customization (no realm selection allowed)
C3  – Integrated Windows Authentication (IWA) is performed at STS and claims are processed.
C4  – Client is redirected to web application (RP)


To make the above scenarios work, some minor customization is needed. The first barrier that we hit is home-realm discovery. If AD FS trusts two additional claims providers, besides Active Directory, how can authentication requests be routed correctly?

The answer rests partly with tweaking the AD FS proxy and farm configuration, the other in the way the Portal IdP calls AD FS. The customization on the AD FS side is relatively straightforward.

Let’s look  at each access scenario:

1. External SP-initated sign-on

In external scenarios that are initiated at the relying party or service provider, we want to use the strongest authentication possible, our 2FA provider. This is accomplished by editing the homerealmdiscovery.aspx.cs on farm members and inserting the following line on the Page_Init section.


2. External IdP-initiated sign-on

IdP-initiated sign-on envisages the use of access gateway solutions such as Juniper SA / Citrix CloudGateway. In these scenarios the user authenticates  to the gateway using the authentication mechanism required by the organization. Access to back-end applications is then performed using service provider initiated sign-on. Having already authenticated at the gateway, with the gateway configured as a claims provider on the AD FS side, the user is not prompted for credentials again and SSO to the application is  provided.

This scenario has some  interesting use cases. It allows the organization to use a different authentication method for accessing the gateway IdP than via the service provider initiated sign-on route (2fa). If the gateway employs some form of endpoint component checking and machine validation, then the organization may wish to adopt a more lenient access and user friendly authentication mechanism for managed/trusted devices (e.g. username/password).

Integration with AD FS is accomplished through using smart-links and selecting both the claims provider, via the home realm parameter (whr), and the relying party (wtrealm), in the query string, e.g.

NB: I’ve omitted Forefront UAG in this list as its relationship with AD FS is that of a relying party rather than an identity provider. Redirects using the whr= parameter to a stronger authentication provider than AD FS are possible.

3. Internal SP-initated sign-on

In this scenario, we want the relying party of SAML 2.0 service provider  to select the Active Directory authentication provider, rather than the other two trusted claims providers. This is accomplished by editing the homerealmdiscovery.aspx.cs on farm members and inserting  the following line on the Page_Init section.

SelectHomeRealm( PassiveIdentityProvidersDropDownList.SelectedItem.Value );

This will automatically select the highlighted item, the native provider always the first chosen.


In this post we’ve looked at supporting multiple claims providers for AD FS with the minimum of customization.  Changing the homerealmdiscovery.aspx.cs file on the  AD  FS farm ensured all internal authentication requests are  passed to Active Directory.  Similarly, externally, we specified the realm the AD FS proxy should use to select the 2FA provider. With home realm discovery now set both front and back-end servers, additional claims providers that support IdP-initiated sign-on may be used and invoked through smart links.

Juniper SA and AD FS 2.0 Integration – Part 2

The recent release of the new 7.2 firmware for the Juniper SA and a timely nudge from colleagues, proved the perfect tonic to continue the second post about integrating the Juniper Secure Access service and AD FS 2.0. 

In Part 1, the article emphasized the use of the Juniper gateway as a SAML Service Provider, with AD FS acting as the Identity Provider. Login at the Juniper, via service provider initiated (single) sign-on, would take place via the AD FS identity provider.  What I neglected to mention in the previous post (silly me), is where this sort of setup can be used, so here are a few examples:

  • as a rendition layer for Citrix Web Interface / StoreFront, for internal users  with Kerberos SSO enabled
  • as a landing page/portal for internal users with Kerberos SSO enabled
  • use of AD FS as an identity provider for single sign-on to MS applications
  • use of AD FS for performing claims augmentation

In this post, we’ll look at the Juniper as an identity provider. In this role role it offers a number of capabilities

  • as a policy enforcement point for managed and unmanaged clients of federation protocols
  • as an authentication bridge between SAML and other protocols for federated SSO scenarios, e.g. RADIUS 2FA/OTP
  • as an Identity Provider (gateway mode)
  • as an Identity Provider (peer mode)
  • as an Access Portal

On the AD FS 2.0 side, AD Federation Services occupies the role of  SAML Service Provider and Relying Party  Security Token Service (RP-STS) to Windows applications running behind it.

There are two operational modes for the Identity Provider, using SAML SSO, that are particularly interesting with the 7.2 release of the Secure Access gateway. These are:

  • Gateway Mode
  • Peer Mode

NB: SAML SSO scenarios described are using HTTP POST.

Gateway Mode

In Gateway Mode, access to web applications / SAML service providers and traffic flows are through the Juniper as a portal. In this mode, logon is initiated at the SA as the Identity Provider (IDP-initiated) and then access is provided to the web application.


In Gateway mode, if the application is on-premise, we can also place the relying party / web application directly behind the Juniper, with the application host [A] record resolving to the gateway address). This configuration is not described in this post.

Here’s a walk-thru of Gateway Mode logon.

1. The user access the URL for the SA gateway and is presented with a logon form.


2. From the portal landing page, the user selects the web application, e.g. Contoso Web, and the request is processed. The behaviour may change according to how the web application has been configured in the web resource profile.


3. The relying party web application redirects the request to AD FS . If a home discovery realm (HRD) cookie doesn’t exist, the user will be requested to do the realm selection in order to logon to their home realm. If smart links are being used for the bookmarked web application(s)  (see later in this post for a further explanation) , then HRD selection may be bypassed.  If smart links aren’t used and realm persistence is also disabled in the AD FS configuration, then the user will be prompted each time to select their home realm, otherwise a cookie of 30 days (default) will be written to disk, once authenticated.


4. The logon request will be submitted to the Identity Provider (IdP). If the user has a valid logon ticket then further logon processing will continue.

5. Once processed correctly, a SAML redirect back to the AD FS server is carried out for further logon and claims processing at the RP-STS.

6. Claims processing at the RP-STS is carried out and it and relying party claims are processed, the user obtains access to the web application.

Peer Mode

In Peer Mode, access to SAML service providers is not initiated via the Secure Access (SA) gateway.  The user accesses the resource directly and they are redirected to the Identity Provider for logon .


Normally speaking, the user is redirected from the service provider to the identity provider for sign-on.  In this configuration, however, behavior is different as AD FS is brokering authentication traffic for web applications that are WS-Federation based and acts an intermediary or Relying Party Security Token Service (RP-STS) between the application and the Juniper.

In Peer Mode, the user will begin RP or SP-initiated logon. Let’s look at the process of how a Windows Identity Foundation (WIF) application behind AD FS 2.0 would work:

1. The user accesses the Contoso web application URL

2. The user is redirected to the AD FS RP-STS

3. The home realms discovery process within AD FS service and user must select the Juniper SA claims provider.

4. The user is redirected to the Juniper Secure Access Service for logon processing


5. The user is presented with a logon form, within which their Juniper logon credentials must be entered. In the example above we’re doing a login against a primary authentication server (RADIUS using One-Time Passwords) and the local Active Directory as a secondary (uid/password).

6. Following a successful logon, the user is returned to the SAML 2.0 Service Provider, AD FS 2.0, for further processing of logon and claims.

7. The Relying party claims pipeline is processed and claims are harvested.

8. If authorized, the user has accessed to the web application.


URL Rewriting

On the Juniper configuration side, to allow successful processing of redirects to AD FS, we need to ensure that the URL of the AD FS is not rewritten at the Secure Access appliance. This is accomplished by the creation of a Web Resource Profile that includes an Autopolicy: Rewriting Options policy set to No rewriting.


We will use this facility later on when we create bookmarked applications and smart-link to our relying party web applications through the AD FS web resource profile.

Identity Provider Configuration

Let’s look at the Identity Provider (IdP) capability of the Secure Access Service. Under Configuration | SAML | Settings of the SA we need to configure our Identity Provider (IdP) with a Host FQDN for our SAML service.


(We’ll cover Pulse NC in a later post)

It is possible to set a different Host FQDN from the gateway or use the gateway name itself. Experience/testing so far suggests that both configurations work. For simplicity, I’ve aligned the FQDN for SAML with the Host FQDN for the Juniper gateway itself ( Once the FQDN are set, there’s also an option to update entity IDs that already exist with the new FQDN. While it won’t automatically update the metadata of partners, it is a handy way of automatically updating entity IDs on the Juniper side.

Next up, a menu option under Authentication | Signing-In | Sign-In SAML is new for 7.2. This provides two configuration tabs, one for the metadata provider and the other for the identity provider.


The Metadata provider Entity ID is automatically populated with the FQDN defined earlier.

On the Identity Provider tab, we configure the main settings for our IdP.

In the first area of the page, we define what bindings we intend on using, use of signing certificate, token decryption certificate etc.


In the second section, we define Service-Provider related settings for the Identity Provider


I want to spend a little time expanding on authentication scenarios and  what kind of logon scenarios are possible.  The Sign-in Policy value allows the administrator to select which policy is to be effective for the IdP. In the example above, I’ve elected to use */ which also happens to be the default sign-in policy for the gateway itself. However, I can customize the sign-in policy so that the IdP has its own authentication scheme independent of gateway mode settings.


In this test configuration, the default sign-on policy is using RADIUS (OTP) and AD authentication.  I’ve setup sign-In policies /idp1 and /idp2 just to illustrate that other sign-on options are available for choice.  Any service provider (including AD FS 2.0) configured with the Juniper as its Identity Provider will be redirected to the Juniper for sign-on, processing the /* policy.


On the IdP configuration screen above, I’ve highlighted the User Identity section. This is the SAML Name Identifier that the IdP will present to the service provider (SP) in the assertion. In this case, I’ve set the Subject Name Format to Other. This translates to NameID unspecified: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

On the AD FS 2.0 side (in Gateway and Peer configurations), the Juniper is configured as a claims provider. Using our mythical FQDN, let’s add a Claims Provider and enter the FQDN of the Juniper as the URL


Walk thru the remainder of the wizard, give the IdP a name, skips claims rules configuration and from within the properties of the claims provider, switch the secure hash algorithm to SHA-1. Using the NameID Unspecified example above, we can add the following custom claims rule:

c:[Type == "", Properties[""] == "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"]
=> issue(Type = "", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

In the above rule we map NameID to Windows Account Name. On the Relying Party Contoso web application, we then pass thru Windows Account  Name to the claims-aware web application.

c:[Type == ""]
=> issue(claim = c);

Peer Service Provider Settings

Within the Identity Provider configuration screen within the Secure Access Service, we also define a list service providers  that make make use of the identity provider. This provides additional options concerning  the Service Provider configuration, and we can elect to override the default sign-on policy for the Identity Provider (IdP).


In overriding the default configuration, it is possible to assign a unique authentication scheme (sign-on policy) and assertion mapping  to a particular service provider. This is useful in scenarios where we wish to use a given authentication type for a particular service provider or web application.

Gateway Mode Configuration

For an IdP-initiated logon, users will typically logon to the FQDN for the gateway (e.g. and the default sign-on policy (/*) will execute.  Using the example described earlier in Peer mode, this would mean the user logs on to authentication realm A using RADIUS (OTP) plus AD password for logon. Since the identity provider is associated with this sign-on policy (/*), this means a valid SAML token is generated at the gateway during login.

To test this, create a Web Resource Profile for the web application, using a custom resource profile for a claims-aware test web application. Click on Show ALL autopolicy types and ensure that AutoPolicy:rewriting options are set to No rewriting for the URL of the web application


As can be seen in the above example, the web application I’ve created is for a  sample WIF application


Add the default Users role to the Selected Roles (or roles of your choice).


A bookmark is automatically created for the web resource profile.

Let’s logout of the administration interface and logon to the gateway (e.g.


The user must enter their user ID, AD password and PIN/OTP code.


In the web bookmarks, we see the Contoso Web application created earlier.

Clicking on the Contoso Web application will take us to the WIF application and initiate Steps 1-8 described in the Peer Mode Configuration, with the notable exception that Step 4 will now be removed as we already have a valid SAML token (and AD FS trusts the Juniper IdP as a Claims Provider).

All good, but when I hit the AD FS proxy, I hit that pesky home discovery dropdown and users must choose between AD FS or Juniper as their claims provider.


This process of having to select the home realm may be acceptable to your users, but if not, we need to look at alternatives that address this home realm issue.

Smart Links and IdP-Initiated Sign-On

Smart-links may be familiar to those who work with Office 365. They can be used in conjunction with applications such as Outlook Web App, to reduce hop count and speed up the login process.  A good article on them can be found here:

They potentially have a role to play with IdP-Initiated Sign-On scenarios with the Juniper where web application and single-sign on can be processed  with the minimum of fuss and limit user intervention in the sign-on process. More importantly, we can bypass home realm discovery for the Juniper IdP as a  claims provider. This can be accomplished by incorporating smart links into bookmarks.

For example, let’s say that the URL of AD FS 2.0 server is I can provide information in the query string about my relying party and the claims provider that needs to process the logon,  accomplished through the wtrealm (relying party) and whr (claims provider) values. This is particularly useful because the home realm discovery selection process in AD FS, where the user has to select the claims provider (e.g. AD or Juniper) can be confusing. By creating a web resource profile for  AD FS, we can exploit the use of smartlinks for bookmark / hot linking access web applications. Using the examples from earlier, I want to create a bookmark for my Contoso web application.

To accomplish this, on the Juniper, we can update the AD FS web resource profile and go to the bookmarks tab. We can then create a new bookmark, Contoso Web  (you’ll need to clean up the stale Contoso Web bookmark that was creating earlier in the post to avoid duplicates) and use the following URL:

This allows bypassing the home realm discovery dropdown and go directly to the IdP (Juniper) for sign-on.

Note that SP-initiated sign-on is still possible. If we do not wish to allow this or wish to handle it differently, there are a couple of further options. On the AD FS proxy instance we may choose to:

Home Realm Discovery Cookie Persistence

Under the <microsoft.identityServer.web> of the web.config on the AD FS proxy, we can disable persistence for the identity provider selection

<persistIdentityProviderInformation enabled="false”

This limits the validity of the identity/claims provider selection to the current browser session, meaning that home realm discovery and the provider selection dropdown will re-appear next time the user logs on.  If you’re not customizing home realm discovery on the AD FS proxy then it’s probably a good idea to set this value.

Note that this changes are limited to and scope-wise affect the AD FS proxy only.

Mixing IdP and SP-Initiated Sign-On

So far in the configuration examples, we’ve aligned IdP and SP-Initiated Sign-On, using the same authentication schemes. However, there are scenarios whereby this may not be desirable. In an IdP initiated sign-on scenario, for example, we may wish to use some sort of additional controls (e.g. host-checking) on the Secure Access gateway for clients. For managed clients, should the client pass host-check validation, we may wish to accept a weaker form of authentication (e.g. username and password)  at the gateway. Conversely, in peer mode, we may opt to continue to use two-factor authentication, irrespective of the client type, because we are bypassing host-checking functionality.  This flexibility is possible because we can shift the sign-on policies and override the default peer mode configuration for our service provider (AD FS). This allows us to take advantage of the security handshaking/enforcement capability of the SA platform to better effect, and, at the same time, allows things such as browser favorites/bookmarks to be preserved when accessing the service provider via SP initiated SSO, something that gateway-induced logon is often accused of breaking.

In either case, on the AD FS side, no change in the claims provider configuration is required because the switching is handled on the Juniper side, according to whether IdP or SP-initiated logon is taking place.



From an access scenario point-of-view, I’ve been looking at cases where both the Juniper and AD FS can operate in an IdP capability.  Internally, AD FS 2.0 can fill the gap and act as an internal identity provider to the Juniper (service provider) for claims-enabled processing and Kerberos SSO capability. Externally, the Juniper provides a broad access platform to operate from and, in turn, an identity provider to AD FS and indirectly relying party applications behind it. In a split DNS configuration this allows you to reap the benefits of both platforms (as per the diagram above).

As ever, test, test, test and break the back of that beast they call test before putting this sort of thing into production…

Have fun!

Juniper SA and AD FS 2.0 Integration – Part 1

Following up from the last post where we integrated OpenAM as an identity platform with Active Directory Federation Services (AD FS) 2.0, we’re going to flip roles and products this time. In this post, we’ll look at using a Juniper SA SSL-VPN gateway and plugging this into AD FS 2.0  Since Release 7.1R1 of the SA firmware, SAML 2.0 support has been available with the platform, with the SSL-VPN being deployable in the guise of a SAML Service Provider, Identity Provider or as a Policy Enforcement Point (PEP).

In Part One of this article, we’ll examine the role of the Juniper SA as a SAML 2.0 Service Provider (SP) and AD FS 2.0 as the SAML 2.0 Identity Provider (IP).


In Part 2we’ll reverse roles, using the Juniper as an Identity Provider (IdP) and AD FS 2.0 as the Service Provider (SP). Note that at the time of writing, the IdP capability in the 7.1Rx release, as I understand it, is not yet fully feature complete (The J-SA release used in this particular post is 7.1R6.0), with the full feature set available in the 7.2 release: expected Q2 2012.

Before we begin configuring our Juniper as a SAML 2.0 Service Provider, there are a number of steps that we need to perform on the Juniper side first. First, the prerequisites:

  • you have a running Juniper SA and AD FS 2.0 configuration ..
  • you have the necessary SSL certificates for your appliance/application (e.g., etc.) and installed them
  • you have a token signing certificate on the Juniper (e.g. self-signed certificate).
  • you have set time correctly on all devices are using a reliable time source (e.g. NTP)

Juniper SA Service Provider

Login to the Administrator Sign-In page of the Junos Pulse Secure Access Service.

From a federation standpoint, the SA will use the hostname, defined in System | Configuration | Networks, in entity IDs and names for SAML Endpoints, unless the appliance is part of a cluster, in which case the Cluster FQDN should be used.

Begin by creating a New Metadata Provider.  Go to System|Configuration|SAML and click the New Metadata Provider button.


Give the metadata provider a name, e.g. AD FS Identity Provider. The administrator is then given the option of uploading the metadata file from the identity provider or connecting to the remote IdP to obtain metadata. I elected to go with the file route, as trying to obtain the remote metadata produced errors (Extract metadata info failed : Metadata file does not have a valid saml entity). I assumed this was down to the federation metadata not being interpreted correctly as it contains WS-Trust metadata.

Download the federation metadata from your local AD FS 2.0 instance, e.g. and save the XML file to disk. The file needs sections of metadata WS-* protocols removed from it as well as Service Provider metadata. Remove the following sections.

  • ds:Signature
  • Role Descriptor
  • SPSSODescriptor

You should be left with a metadata file that looks something like this:


Upload the metadata file.


If the file is formatted correctly, it will be accepted when the configuration is saved.


In the Metadata Provider Verification Configuration section, we need to import the AD FS Token Signing Certificate. This certificate can be exported from the AD FS 2.0 Management snap-in by clicking on the AD FS 2.0|Service|Certificates section, double clicking on the certificate, highlighting the Details tab and then pressing the Copy to File button. Select Base64 in order to use a format supported by the Juniper, save to file and then upload the certificate on the Juniper configuration. In the example below Certificate Status Checking is also enabled.


Save the configuration.

From the main Junos Pulse Secure Access menu select Authentication|Auth Servers. From the dropdown selection choose SAML Server and click on the New Server button.


Give the new configuration a name, e.g. AD FS ..


Change the SAML Radio button to 2.0. As soon as this is done the service provider entity ID of the Juniper SA will be populated. The SA entity ID defined here for this SAML Server is unique to this SP-IDP pairing.


What I mean by this is, is that if I have two SAML servers in the Authentication Servers section on the Juniper, with each one pointing to a different Identity Provider, the SA Entity ID for each entry will change. For example, the service endpoint may be: for Service Provider A and Identity Provider A pairing for Service Provider B and Identity Provider B pairing.

Make a note of the endpoint/entity ID information at this point so we can cut and paste this into AD FS later.

In the next section we need to specify the remote partner that the SA will be paired to for this SAML Server entry. Since we’ve already defined AD FS 2.0  as a potential identity partner in System|Configuration|SAML, the entity ID and Single Sign On Service URL is automatically populated when we click on the Metadata radio button.


We can always configure the settings manually, but we’ll then need to enter SSO URLs and Entity IDs manually for AD FS.

Change the configuration mode to manual so that:

  • SSO Method is set to Post
  • the Signing Certificate can be specified.


I’ve also selected a Device Certificate for Signing the metadata.


A self-signed certificate can be created using OpenSSL, IIS7.x, Portecle (see previous posts) and then the .P12/.PFX file imported into Configuration|Certificates|Device Certificates section of the Juniper.


In the Service Provider Metadata settings section of the SAML Server there is an option to not Publish SA metadata. If this checkbox is enabled, AD FS 2.0 will not be able to connect to the SAML endpoint of the Juniper to service metadata. In which case the Service Provider metadata will need to be exported to file from the Juniper via the Download Metadata button and then import it manually into AD FS. In this post, we’re using published endpoints.


Click on Save Changes when you’ve finished entering the SAML Server information

As a final step, we can create a separate User Authentication Realm in the SA Configuration or associate the authentication server with the default Users realm. In the example below, a realm called AD FS IdP is created and the AD FS authentication (SAML) server specified.


On the default sign-in pages, the AD FS IdP realm has been chosen to use for logon.


AD FS 2.0 Identity Provider

In AD FS 2.0, we’ll need to create a Relying Party via Relying Party Trusts |  Add Relying Party Trust option.

Enter the URL of the Juniper SA endpoint (this is the SA Entity ID information from earlier)


Click on Next and give the Relying Party/Service Provider entry a name.


Click on Next


With the Relying Party information entered we can then enter the necessary claims rules to pass to the RP.


We’ll do this by:

  1. Creating a rule that extracts the e-mail address from AD
  2. Create a transform rule that transforms the incoming claim type: e-mail address to the Outgoing claim type: NameID with the Email format

Under Issuance Transform Rules, Click on the Add Rule button and select the Send LDAP Attributes as Claims template.

From the AD Attribute Store, we’re going to map the LDAP attribute E-Mail-Addresses to an outgoing claim of e-mail address. Click on Finish when done.


Add a second rule. Create a Transform an Incoming Claim rule and in this rule, we’ll map the incoming E-Mail Address claim to an outgoing claim type of Name ID using the format Email. *


Click Finish when done.

If you attempt to access the Juniper gateway, an get the following error:


Double-check that the claims values you’ve entered are set correctly.

If you get an error such as the following:


This may occur because the signature value on the relying party in AD FS is set to SHA-256 instead of SHA-1. Additionally, the error can occur because of issues with the relying party URI. When we have a look in the AD FS 2.0 admin log, we see an Event ID 184:

A token request was received for a relying party identified by the key ‘;, but the request could not be fulfilled because the key does not identify any known relying party trust.

This request failed.

User Action
If this key represents a URI for which a token should be issued, verify that its prefix matches the relying party trust that is configured in the AD FS configuration database.

Looking at the Service Provider metadata from the Juniper service through its URL (, the entity ID does not match the expected identifier reported in the event log error ( When setting up the Service Provider, the identifier is set to

Go into the relying party settings for the Juniper and on the Identifiers tab add an additional identifier for

Go to the Sign-In page configured


You should be able to logon successfully to the Juniper portal using your AD credentials.


As ever, test extensively before trying to put this into any production level environment.

* NameID mappings from the Juniper Service Provider metadata