Security and Identity in the Cloud

Custom HomeRealmDiscovery Page with AD FS 2.0

2012-09-19T03:59:05Z

Recently I decided to dissect the structure of the default pages in AD FS 2.0 and see what can be done with creating slightly different look from its default look. I wanted to see what files control what areas in the UI and what can be done with minimum code changes.

I started working with one of the most common pages accessed in large implementation – the Home Realm Discovery page. As you probably know, the default look of this page is like this:

As part of this exercise I wanted to make it look like this:

The main page that is accessed to present Home Realm Discovery is HomeRealmDiscovery.aspx. So the first step I took a look at it to see what it is doing and if it using any other support pages. As I suspected, the site is designed to use different files for HTML, C# and CSS code. It also has special language files that contain all the configurable text strings in the UI. Some configuration is done via web.config file. Overall, to move from the default UI to my customized UI I had to modify six files and introduce two graphic files.

The following files have control over the Home Realm Discovery:

Inetpub\adfs\ls\web.config
Inetpub\adfs\ls \HomeRealmDiscovery.aspx
Inetpub\adfs\ls \HomeRealmDiscovery.aspx.cs
Inetpub\adfs\ls\App_GlobalResources\CommonResources.resx
Inetpub\adfs\ls\App_GlobalResources\CommonResources.en.resx (and many other language files, if you need to present it in those languages)
Inetpub\adfs\ls\MasterPages\StyleSheet.css
Inetpub\adfs\ls\MasterPages\MasterPage.master
Inetpub\adfs\ls\MasterPages\MasterPage.master.cs

Files with .CS extension contain C# code and I did not change them. All the logic associated with proper functionality of the AD FS for presenting the target IdPs, and other AD FS related functionality is done via those pages, but they are not controlling the UI for the Home Realm Discovery page.

On the following diagram I’ll point out what area in the Home Realm Discovery page is controlled by what configuration file.

1. The background. It is controlled via StyleSheet.css. To modify it you’ll need to modify background-image: in BODY section. By default it is using url(../App_Themes/Default/header_background.png) image. You can replace this with another image of your liking to show in the background. Image can introduce nice color change with shades and such, but you can also just specify the solid color via the tag.

2. Header. The text for the header comes from the CommonResouces files. How it is viewed is controlled by the StyleSheet.css and MasterPage.master files. I replaced the default “Sign In” text with “Contoso Federation Services”, changes style sheet to reflect different font color and its size, tags in style sheet were also used to fine tune its placement. I also had to move its location in the MasterPage.master file so it would appear to the right of the logo, and not above it.

3. STS Title. The title you see here comes from the AD FS Federation Service name you define on the AD FS Properties. The same name you see in the drop down list when you need to select your target IdP. The placement code for STS Title is controlled in MasterPage.master and via style sheet. I removed STS Title from the final page. I had to do this by introducing a new code in the style sheet and replacing the class definition in the MasterPage.master with new style that hides it.

4. The text shown inside the main area comes from the CommonResouces files. The code that defines its placement is controlled via HomeRealmDiscovery.aspx file. You’d need to introduce new sections in it with new Label Text ID and create corresponding Label Text entries in the corresponding CommonResouces files.

5. Text in the button is controlled via CommonResouces files. Its placement can be controlled via HomeRealmDiscovery.aspx file and visual elements via style sheet.

6. The border is controlled via style sheet. Elements like its sickness, colour, how wide etc

7. Optional Logo can be introduced by specifying it via web.config file. Its placement on the page is controlled via the MasterPage.master file and style sheet.

Easy! Right?

OK, so if you like to see more details, here is a bit more on the each change to get from default look to my custom look.

1. Background. Modify StyleSheet.css from this:

body

{

background-color: #ffffff;

color:#222222;

font-size: 0.8em;

font-weight: normal;

font-family: "Segoe UI", Verdana, Tahoma, Arial, sans-serif;

margin: 0px;

background-repeat: repeat-x;

background-image: url(../App_Themes/Default/header_background.png);

}

To this:

body

{

background-color: #ffffff;

color:#222222;

font-size: 0.8em;

font-weight: normal;

font-family: "Segoe UI", Verdana, Tahoma, Arial, sans-serif;

margin: 0px;

background-repeat: repeat-x;

background-image: url(../App_Themes/Default/custombackground.gif);

}

2. Header. First, in MasterPage.master move the following code

<div class="Header">

<asp:Label ID="PageTitleLabel" runat="server"></asp:Label>

</div>

From being in front of the

<%

string logoPath =

System.Web.Configuration.WebConfigurationManager.AppSettings[ "logo" ];

if( !String.IsNullOrEmpty( logoPath ) )

{

%>

<div class="GroupXLargeMargin">

<img src="<%= logoPath %>" alt="logo" />

</div>

<%

}

%>

To be behind it, so it looks like this:

<%

string logoPath =

System.Web.Configuration.WebConfigurationManager.AppSettings[ "logo" ];

if( !String.IsNullOrEmpty( logoPath ) )

{

%>

<div class="GroupXLargeMargin">

<img src="<%= logoPath %>" alt="logo" />

</div>

<%

}

%>

<div class="Header">

<asp:Label ID="PageTitleLabel" runat="server"></asp:Label>

</div>

Second, update StyleSheet.css Header to look like this:

.Header

{

color: #000000;

padding: 8px 0 5px 0;

margin-bottom: 1px;

font-size: 200%;

font-weight:bold;

position:relative;

left:184px;

top:-95px;

}

And finally, replace “Sign In” text in both CommonResouces files for HomeRealmDiscovery text label to be “Contoso Federation Services”.

3. STS Title. To hide it you can do the following:

a. In MasterPage.master page change the following code

<div class="TextSizeXLarge">

<asp:Label ID="STSLabel" runat="server"></asp:Label>

</div>

To look like this:

<div class="STSTitleNotVisible">

<asp:Label ID="STSLabel" runat="server"></asp:Label>

</div>

b. In StyleSheet.css create new code for STSTitleNotVisible to be this:

.STSTitleNotVisible

{

visibility:hidden;

}

4. To introduce new text in the main section update HomeRealmDiscovery.aspx file with new Label Texts and introduce that text to the CommonResouces files.

a. In HomeRealmDiscovery.aspx make <asp:Content section to look like this:

<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" Runat="Server">

<div class="GroupXLargeMargin">

<asp:Label Text="<%$ Resources:CommonResources, HomeRealmSelectionText%>" runat="server" />

</div>

<div class="GroupXLargeMargin">

<asp:Label Text="<%$ Resources:CommonResources, HomeRealmSelectionTextTwo%>" runat="server" />

</div>

<div class="GroupXXLargeMargin">

<asp:DropDownList ID="PassiveIdentityProvidersDropDownList" DataTextField="Name" DataValueField="Id" runat="server"></asp:DropDownList>

<asp:Button runat="server" ID="PassiveSignInButton" Text="<%$ Resources:CommonResources, HomeRealmSignInButtonText%>" EnableViewState="False"

OnClick="PassiveSignInButton_Click" CssClass="Resizable"/>

</div>

<div class="GroupXLargeMargin">

<asp:Label Text="<%$ Resources:CommonResources, HomeRealmSelectionTextThree%>" runat="server" />

<a href="mailto:Helpdesk@contoso.com?subject=FEDERATION">Helpdesk@contoso.com</a>

<asp:Label Text="<%$ Resources:CommonResources, HomeRealmSelectionTextThreeHalf%>" runat="server" />

</div>

<div class="GroupXLargeMargin">

<asp:Label Text="<%$ Resources:CommonResources, HomeRealmSelectionTextFour%>" runat="server" />

</div>

</asp:Content>

b. Add the following to the CommonResouces files:

<data name="HomeRealmSelectionTextTwo" xml:space="preserve">

<value>NOTE: The following Identity Providers will let you into the application.</value>

</data>

<data name="HomeRealmSelectionTextThree" xml:space="preserve">

<value>If your Organization is not listed, please send an e-mail to the contact at </value>

</data>

<data name="HomeRealmSelectionTextThreeHalf" xml:space="preserve">

<value>and express your interest of your Organization becoming a member of the Federation Framework, and include the name of the application that you are trying to access in your e-mail.</value>

</data>

<data name="HomeRealmSelectionTextFour" xml:space="preserve">

<value>If you believe that you have arrived at this page by accident, please close your web browser and try accessing the application webpage URL again in a new browser session.</value>

</data>

5. The button is moved to be at the same level as the drop down list. This is controlled by removing <div> tags that surround the button code in the HomeRealmDiscovery.aspx.

6. To control the border just change the style sheet .MainActionContainer with this details:

.MainActionContainer

{

padding: 5px 20px 5px 20px;

border: solid 3px #003300;

min-height: 150px;

position:relative;

top:-30px;

}

7. Finally, to add the logo do the following:

a. Modify web.config file by uncommenting code that specifies the name of the logo file and then place your logo file in the root folder of AD FS (Inetpub\adfs\ls\)

b. In MasterPage.master change the following code

<div class="GroupXLargeMargin">

<img src="<%= logoPath %>" alt="logo" />

</div>

To look like this:

<div class="CustomLogo">

<img src="<%= logoPath %>" alt="logo" />

</div>

c. And finally, add new code to the StyleSheet.css:

.CustomLogo

{

margin-top:25px;

}

After doing all these changes, the default looking page

Will look like this:

Easy, Breezy, Cover…. Hmm, page.

Visit me at http://CloudIdentityBlog.com

Till next time!

Chaining Multiple STS

2012-08-18T15:27:16Z

A few month ago I learned something about claims based authentication that I thought was not possible.

Ever since starting working on federation solutions, and learning about it via training courses, reading white papers, specifications and presentations the following two topologies were always shown or discussed. The first one is where company has its own STS and their applications configured with this STS. The second solution extends on the first one by federation between two STSs, where one STS is acting as RP and the second is acting as IdP. I have never seen any specs or designs that would show more than two STSs in a chain, ie something like this RP-RP-IdP. So for some time I was assuming that protocols that make it all happen (WS-Fed, SAML etc) are designed to work in specific model RP-IdP and would not go beyond this one-one relationship. While this works for majority of the real world situations, in some cases it does not satisfy the complex requirements where chaining of the multiple STSs is required. Well, I thought that it was not possible till a few month ago. I had to design complex federation architecture and this perceived limitation was giving me a lot of headache. So, obviously I did some research and talked to a few people who also specializes in federation solutions and to my great surprise I learned that there is no limitation with protocols and that it is just fine to setup multiple STSs in a chain of trusts. I wish that I learned it prior from someone else’s design or spec paper, clearly stating that it is fine to do this and it will work. Needless to say, we were able to configure our architecture and satisfy customer requirements without additional overhead and keep it very streamlined.

A few days ago I was rebuilding my lab and decided to configure it to illustrate chaining of multiple STSs and show it here. So if anyone else didn’t decipher it in spec papers or other design, and is thinking that chaining is not possible, that it is in fact possible and works just fine. You can use it in your designs if it is a requirement.

In my lab I configured the following to illustrate this configuration:

IdP STS (DC, AD FS 2.0), it has the following FS URL: fs1.contoso.com
RP STS (AD FS 2.0), this is a middle STS, with FS URL: fs2.contoso.com
RP STS (AD FS 2.0), this is the STS with target relying party application. FS URL: fs1.external.com
Relying Party (Sample WIF SDK app). This is a workgroup server configured with fs1.external.com as its STS. Application URL https://myclaims.external.com/myclaims
Workstation that will access the application. I have HTTPWatch installed on this PC to show all traffic passive request traffic between the browser and the target systems.

Figure 1 shows my lab configuration:

Figure 1: Chaining multiple STS

Figure 2 shows the HTTPWatch traffic captured on the client PC. As you can see in steps 1 to 10, the browser steps through all parties in the authentication process and authenticates me into the application. It is fairly self explanatory, but if you have questions then let me know if you need any explanation on what happens here.

Figure 2: HTTPWatch capture of the Passive Request traffic with multiple chained STS (click on it to see it large)

Finally, you might ask why would anyone need to chain STS in such way. To answer it I’ll have to write another blog post. So stay tuned, I might do that in the next month or so.

Visit my main blog at http://CloudIdentityBlog.com

Thanks, Dmitrii

Authentication Assurance and Claims Based Authentication

2012-06-27T17:40:53Z

Authentication Mechanism Assurance is described in the following Microsoft publication: http://technet.microsoft.com/en-us/library/dd378897(v=WS.10).aspx.

In this post I want to dig a bit more into different configuration options, show how it works and provide example of how it can be configured with AD FS 2.

Authentication Mechanism Assurance is a new feature in Windows 2008 R2 AD DS configured at 2008 R2 Functional level, it provides an ability to assure that user is authenticated with specific type of certificate. Usually it is used to assure that user is authenticated with a specific type of smart card into AD DS. This assurance can then be passed on to applications which will make authorization decision on what user can or cannot do in it. It is very important feature in environments where specific regulations require to provide assurance of Smart Card authentication.

AD DS configured to use Authentication Mechanism Assurance is capable to identify users who used specific type of Smart Cards for authentication and dynamically populate their Kerberos tickets with security group associated with those specific Smart Cards. The linkage between Smart Card and AD DS is done via the OID populated in Certificate Policy certificate extension. Let’s take a quick look at how it works. The following diagram shows a basic flow of authentication to claims based application which can take advantage of the authentication assurance claim. In our example Contoso has Smart Cards with X.X.XX.XXX.X.X.X.X OID populated in Certificate Policy certificate extension. AD DS is configured to link X.X.XX.XXX.X.X.X.X OID with “Smart Card X Authenticated” security group.

In step 1, user authenticates to their desktop by providing Smart Card and PIN number. During authentication process AD DS detects that user authenticates with Smart Card (it is done by finding X.X.XX.XXX.X.X.X.X OID in the user certs) and builds Kerberos ticket. AD DS will include “Smart Card X Authenticated” security group SID in the Kerberos ticket.

In step 2, user tries to access claims based application which will redirect the browser to its trusted STS.

In step 3 and 4 user will be authenticated to the STS. STS will examine user group membership and because user’s Kerberos ticket contains “Smart Card X Authenticated” SID it will issue special claim type indicating that user was authenticated to AD DS with their Smart Card.

This token will be passed to the application. In step 5, application will have a choice to provide different logic for users who authenticated to AD DS with a Smart Card or without. Simple enough.

Let’s take a look how it all can be configured. I’m not going to repeat some of the steps described in the before mentioned Microsoft publication. I’ll refer to it when necessary.

The first step in configuring Authentication Mechanism Assurance is to create proper Issuance Policy in AD DS. The OID in AD DS Issuance Policy must match the OID in Certificate Policy on the Authentication certificate on the Smart Card. It will look something like this on the certificate:

[1]Certificate Policy:

Policy Identifier=X.XX.XXX.X.XXX.X.X.X.X.XX

More likely your AD DS will not have this OID and you’ll need to create one. Fortunately it is easy to do:

Open Certificate Template management console.
Open any v2 certificate template.
Click on Extensions Tab, Click on “Issuance Policies” and then click Edit.
Click on Add, then click on New.
In the Name field type: Smart Card AuthN Cert
In the object identifier field type: X.XX.XXX.X.XXX.X.X.X.X.XX (where XXX – is the OID from the cert on Smart Card)
Click OK
Do not save changes to the certificate template. Exit Certificate Management Console.

At this point you are ready to link appropriate security group to the Certificate Issuance policy. Create get-IssuancePolicy.ps1 and set-IssuancePolicyToGroupLink.ps1 files as described in Microsoft article. Run the first one to see if there are policies already in place. Run the second to make the linkage.

To display run this: .\get-IssuancePolicy.ps1 –LinkedToGroup:All

To create new policy: .\set-IssuancePolicyToGroupLink.ps1 –IssuancePolicyName "Smart Card AuthN Cert" –groupOU "Auth Mech Assurance" –groupName "Smart Card Authenticated"

To see new policy: .\get-IssuancePolicy.ps1 –LinkedToGroup:All

So far, so good. We configured Authentication Mechanism Assurance. To verify that it actually working logon to AD DS with Smart Card, open command prompt and type whoami /groups. It will list all the groups that you belong, one of them will be Smart Card Authenticated. Logon with UserID/pwd and you’ll not be member of that group.

The next step is really making some use out of this information. Applications must be designed to take advantage of this information and make authorization decisions based on level of assurance we provide to it. Perfect candidates for it are claims based applications. We can generate a claim type, for example lets name it “LOA”, which stands for Level of Assurance, and assign different value to it. If user used userID/pwd, we assign 2 to LOA, if user used Smart Card then LOA will have 3. Application will decide what to do base on those values in LOA claim type.

Next, we are going to create LOA claim type in AD FS 2 and pass it to the application. I’ll discuss it in the next post.

Thanks for stopping by. See my other blog as well http://CloudIdentityBlog.com for this information and some comments.

New UAG Book - Mastering Microsoft Forefront UAG 2010 Customization

2012-03-27T13:04:12Z

My last few posts were dedicated to customization of the look and feel of the UAG 2010 Logon/Logoff and Portal experience. I had to figure out a lot of it on my own without any type of documentation. Well, there is a good news, PACKT Publishing just released a new book on how to customize UAG implementation. It is written by the same folks who wrote a must have book on UAG Administration, and published from the same publisher. If you are doing any work with UAG 2010 then both of these books should be in your library!

I just had a chance to read through the new book. It covers a lot of different topics and shows how to customize UAG installation, and at the same time keep it in supported condition.

You can check it out at the publisher web site http://www.packtpub.com/mastering-microsoft-forefront-uag-2010-customization/book

UAG 2010 Custom Logon and Logoff Pages

2012-01-23T00:12:02Z

Ever needed to modify UAG 2010 default Logon/Logoff pages to something a bit more custom? I did on one of my recent projects.

See it for more details on full width page on my blog at http://cloudidentityblog.com/white-papers/uag-2010-custom-logon-and-logoff-pages/

Thanks,
Dmitrii

UAG 2010 Custom Portal

2012-01-19T01:47:16Z

Ever needed to modify UAG 2010 default portal page to something a bit more custom? I did on one of my recent projects.

See it for more details on full width page on my blog at http://cloudidentityblog.com/white-papers/uag-2010-custom-portal/

Thanks!

UAG 2010 and AD FS v2 White Paper is Published

2011-11-05T17:42:22Z

Over the last three month I published many articles on UAG and AD FS. While it each of the posts provides its own information, many of them refer or build on the knowledge provided in the prior posts. So if you had to read it altogether you’d have to start from the end and read forward. One continuous document is is easier to read and for that reason I combined all of these posts and published them as a single white paper document. Also, since it is not a traditional blog post, I removed the side bar, which allowed me to expand the size of the diagrams and make them more usable to the reader.

Just follow the following link to access it from my CloudIdentityBlog.com blog:

UAG 2010 and AD FS v2 are Better Together White Paper

AD FS and UAG are Better Together–Example of a real Solution

2011-10-29T14:44:27Z

In the last nine posts we reviewed different topologies and discussed some of the techniques on how to integrate these topologies together. In this post we’ll take a look at real example of a production implementation.

The solution very similar to the following design has been implemented by one of the large enterprise companies. We will review it here in some detail. Every real world implementation is based on some type of specific requirements that the customer would like to satisfy. The solution is called “Application Gateway” or simply “Gateway”. The following are the main requirements that this solution must satisfy:

Provide a secure infrastructure solution that can be accessed by users over the Internet.
Provide an application portal to host applications for access by both internal and external users.
Allow external users to create accounts.
Allow external users to change their passwords.
Provide external users with self-service password reset functionality.
Allow internal users to leverage their current existing credentials for gaining access to the resources in this solution.
Federated access to published applications by partner users.
The solution must be secure, implemented in the DMZ environment, and ideally without Windows trusts between this solution environment and internal AD.

I just listed the main ones, but there are many more specific requirements. Those are not necessarily dictating the overall solution architecture.

The following software components are part of the solution, with Figure 1 showing how they relate to each other:

FIM 2010 R2 - All IDM related functions

Self-registration for external users
SSPR for external users
Group Management for application access AuthZ
Approval Workflows for user creation

UAG SP1 – External and Internal entry into the application hosting environment
AD FS v2 – Authentication into the environment

For external users access to SAML apps
For internal users SSO to Gateway and access to SAML Apps

SCOM/ACS – Monitoring and Audit
AD – Directory Services

Figure 1: Solution Components

UAG Trunk Design in this solution will have at least three trunks on each UAG server, as shown in Figure 2.

The first trunk will publish Anonymous applications. This trunk will be configured without any authentication requirements. The following are primary applications that will be published via this trunk:

Initial landing page for users with menu selection of different tasks
Self Service Password Reset application
Self-User Registration application

2. The second trunk will publish a portal for external users with password change function

This trunk will use AD for primary authentication to the portal
Will use AD FS as secondary for claims-enabled apps

3. The third trunk will publish a portal for users authenticating via SAML (Federated)

This trunk will use AD FS as the primary authentication to the portal
It will be configured as a relaying party with RP-STS

Figure 2: UAG Trunks

Figure 3 shows Federation configuration for this solution. It will have at least three AD FS Farms:

The first farm will act as resource provider, and it will be configured with all applications in the Gateway application environment. All claims-enabled applications will trust this STS. In Figure 23, it is shown as RP-STS (fs2.fabrikam.com). As you can see, both UAG servers, specifically ADFS configured trunks, are some of the applications that are configured as relying parties with this RP-STS.
The second AD FS server farm will provide SAML tokens to external users with accounts in the Gateway Active Directory. It will act as an identity provider to external users who have accounts in the Gateway AD. This STS is shown as IdP-STS (fs1.fabrikam.com). This STS will not be accessed via UAG as by means of UAG proxy. Instead it will be published on the FBA trunk as a secondary authentication provider.
The third AD FS server farm will provide SAML tokens to internal users with accounts in Corporate Fabrikam AD. It will act as an identity provider to internal users. This STS is shown as IdP-STS (fs3.fabrikam.com). This STS is not published via UAG. In fact, it is providing Federated WebSSO to the RP-STS, so that internal Fabrikam users will be able to authenticate into the Gateway environment without being required to have a known UserID/Password in the Gateway AD.

Figure 3: Federation Design

At this point, we need to review a very important technical requirement that must be satisfied for this solution to work. Internet facing UAG and internally exposed UAG must be resolved via the same DNS name. They must be identical. In other words, if an Internet based client types in the browser the name for this portal as portal.fabrikam.com, it should resolve to the external UAG IP address. At the same time, if internal user, using a computer on the corporate network is using the same URL, it should be resolved to the internal UAG server IP address. Why is this the case? It actually has nothing to do with UAG. This requirement comes from AD FS – the federation service URL always stays the same. In our example, if the client needs to get a SAML token from the fs2.fabrikam.com AD FS server, it must be able to resolve this URL and connect to it via that URL. Since this FS service is published via two different UAG servers, both sides of the users must be able access it via the same URL.

The easiest and most common way to satisfy this requirement is by having “split-brain” or dual zone DNS design. Basically, companies would have two different zones with the same name, one exposed to the Internet and one that is only internal. Figure 4 gives a visual demonstration of this requirement.

Figure 4: Split brain dual zone DNS design

Let’s review how different users would authenticate into the Gateway and access published applications. First, we will start with internally based users. Figure 5 provides a high level flow of how internal users will authenticate to the internal UAG server. For internal users whose domain was federated with Gateway, they will use the ADFS trunk as their primary portal. When they try to authenticate, they will be using Federated WebSSO, with first step (1a) accessing RP-STS and performing a home realm discovery, which will redirect them to their internal IDP-STS in step 1b, where they get their initial SAML token, which will be provided back to RP-STS (step 1c). RP-STS will issue the final token, which the client will provide to the ADFS trunk (step 1d), and the user is authenticated to the portal.

Figure 5: Internal user authentication to UAG

After successful authentication, the user will see a list of applications published to him via the AD FS trunk. The authorization to see these applications must be done via contents of the claims. Using normal security groups from Gateway AD will no longer work because the internal user actually does not use Gateway AD for authentication to the portal.

There are two types of applications that are supported via AD FS enabled trunks: Kerberos Applications and Claims-enabled applications.

In this solution, FIM 2010 R2 must be published to the internal users so they can get into the FIM 2010 R2 portal and perform administrative tasks, such as approve or deny external user account requests. FIM R2 is not a claims-enabled application, but it is a Kerberos based application and it can be published via AD FS enabled trunk by using Kerberos Constrained Delegation. Of course for this to work, the Gateway AD must have a shadow account for internal users. FIM R2 will actually help with creating shadow accounts. It is configured to synchronize internal Fabrikam AD user accounts into the Gateway AD, thus creating a shadow account for internal users. It will not synchronize user passwords into Gateway AD.

Figure 6: Internal user accessing Kerberos Applications

Internal users will be able to access FIM R2 via SSO experience and perform their work as needed. Figure 6 shows the basic authentication step for Kerberos based application. In the future, this solution will be able to publish other Kerberos based applications, and they will be accessed in the same way as FIM 2010 R2. They will require proper SPN configuration and Gateway AD, but users will already have shadow accounts.

The other type of applications that can be published via AD FS enabled trunks are claims-based applications. These are easy and straight forward to publish and access via AD FS trunk. Figure 7 provides a high level authentication flow for internal users.

The interesting part in this authentication flow and what is different from the original authentication to the portal itself is the fact that the client does not need to get another security token from its internal IdP-STS. Since he is already authenticated to the portal, after the client tries to access the published application, the client browser will only need to request a new security token from RP-STS, specific for this application, as it shown in Figure 7.

Figure 7: Internal user accessing claims applications

Finally, we can examine authentication flow and application access by external users. There will be two types of external users: users with accounts registered in the Gateway AD for which they know their passwords and federated users, whose identity belongs to some other organization. Each user type will have to use different trunks for authentication.

External users with accounts in Gateway AD will be accessing it by using a UAG trunk with Gateway AD as the primary authentication provider. The primary reason for this configuration is to allow these users to change their passwords and to notify them when their password is about to expire. Trunks that use AD FS as the primary authentication provider do not provide password management functions.

Federated external users will access the portal via UAG trunks with the AD FS server as the primary authentication provider. While these users are important to the future of this solution, the current primary user base will consist of external users with accounts in Gateway AD, and, for this reason, Figure 29 shows the authentication flow and access to applications for these types of users only.

First, the user will need to authenticate into the portal, which will be done via UAG forms based authentication with Gateway AD account. After successful authentication into the portal, the user will be presented with a list of applications, which he/she has been authorized to access. The authorization is based on the AD group membership. The authentication flow to the application will depend on the application type.

Non-claims enabled applications are actually very straightforward. For example, FIM 2010 R2 will be published to external users by using SSO function of the UAG trunks, and it will use the same authentication provider as for the trunk itself. Users will access such applications by utilizing their AD credentials, with UAG taking care of this authentication behind the scenes and without any special type of configuration requirements. This flow is shown as step 2 to Kerberos enabled applications.

Authentication to claims-enabled applications will be a bit more complex. Figure 8 shows it with step 3 flow. The application is published via the FBA trunk portal, and the user will try to access it via that portal. With step 3a, it will contact the application and learn that the application trusts RP-STS. RP-STS is not published via FBA trunk. It is published via ADFS Trunk, a different trunk on the UAG server. In step 3b, the user’s browser will be redirected to the RP-STS to get the token for the target application. Theoretically, we could issue a SAML token at this point in time, but since RP-STS is not published via an FBA Trunk, we will not be able to provide SSO experience to the end user. If we would end the process here, the user would be required to authenticate to RP-STS. Since there is no SSO for this user on the ADFS trunk, he/she will be prompted for credentials. Instead, the Home Realm Discovery will happen, and the user will be redirected to the IdP-STS (fs1.fabrikam.com). IdP-STS is published on the FBA trunk, and it is configured with SSO authentication via Gateway AD. The user is already authenticated to the FBA trunk and via step 3c will authenticate to the IdP-STS and receive security token. This token will be posted back to the RP-STS in step 3d, which will be transformed into a new token, suitable for the target application. It will be provided back to the client computer and posted to the application via FBA trunk in step 3e. The application will authenticate the user and open in the user’s browser.

Figure 8: External User Authentication and Application Access

It is not the most straightforward authentication experience, but as discussed earlier in this paper, configuration of claims-based applications with multiple UAG trunks requires separation between Resource Provider STS and Identity provider STS. Otherwise it will not be published via different UAG trunks.

Authentication of a federated user via an external UAG server is done the same way. It is for internal Fabrikam users, straight forward federated WebSSO.

Things to know about this design:

During the implementation of this solution, we discovered a few restrictions in AD FS that would not be very obvious if we used only one UAG server. However with dual implementation and especially with identical name spaces on Internet and Intranet, we ran into some minor constraints. Fortunately, fairly easy workaround were quickly identified to bypass them.

The first constraint is related to the certificate usage on AD FS. It will not allow the use of the same certificate (certificate with the same hash) on multiple relying parties. Why is this a problem? Since we have the identical name space on the internal network and external network, originally we tried to save on costs and use the same wild card certificate (*.fabrikam.com) on external UAG and internal UAG servers. UAG servers will work just fine with the same cert, but when time came to set them up as relying parties on the AD FS RP-STS server, we encountered a problem. AD FS did not allow the creation of the second relying party with a certificate whose hash had already been used by another relying party. The simple solution to get around this problem is to issue two different wild card certificates, one for internal UAG and one for external UAG. Usually these certificates must be trusted by Internet clients, so you would need to get them from one of the commercial certificate providers, and it will double your cost.

The second constraint is related to the naming of the ADFS Trunks on external and internal UAG servers and the potential conflict with RP-STS Federation Services for each relying party. During ADFS trunk configuration on the UAG server, it is most logical to configure the public URL for the trunk to match the URL of the published Federation server. By default, you would probably create the ADFS trunk for fs2.fabrikam.com AD FS with the same URL, i.e. it will be fs2.fabrikam.com. Then you would proceed to configure AD FS with the UAG relying party, which will configure it with the Federation Service URL as fs2.fabrikam.com. So far so good, we have no issues. Now, we proceed with the configuration of the second UAG server, where we create the UAG trunk for internal users, with the same URL, to match RP-STS, ie, fs2.fabrikam.com. This is done without any issues on the UAG server. The second step in configuration will be the creation of the relying party trust on the AD FS server. AD FS will not allow you to create the relying party trust to the second UAG server. This is because it is using the same URL as the first one, and AD FS will not allow two relaying parties with the same URL. Fortunately, there is a workaround for this as well. All you need to do is to configure each ADFS trunk with its own unique URL, different from the RP-STS URL. For example, the external UAG AD FS Trunk can be configured with the following URL for its public name: fs2e.fabrikam.com, and internal UAG AD FS trunk can be configured with the following URL for its public name: fs2i.fabrikam.com. When configuring each UAG server with RP-STS, they will appear as different relying parties, and AD FS will be happy. One thing to remember is to make sure that DNS is configured to resolve fs2.fabrikam.com to each respective UAG trunk, i.e. it needs to point to the same IP address as its internal or external public trunks URLs.

Thanks!

Designing UAG and AD FS Solution

2011-10-19T02:44:25Z

In the last many posts we looked at all kind of different topologies for UAG and AD FS configuration.

Now, since we are armed with knowledge of different configuration options, we can put all of them to use and see how we can apply them to real life situations. Before we do this, we need to revisit some critical technical requirements that exist with UAG and ADFS v2.

The UAG server can use the same AD FS v2 Federation Service URL only in one UAG trunk. This constraint is very important to understand because it is one of the critical elements that will affect your design.
Based on the previous requirement, if your configuration requires multiple UAG trunks with AD FS v2 support, and we will examine shortly why this might be the case, you will need to implement a separate AD FS v2 server for each UAG trunk.
UAG can provide Kerberos Constrained Delegation (KCD), but with the following constraints:

The UAG server must be in the same AD domain as the application server it is trying to access;
The User Account used to authenticate to the UAG server (the one we need to use KCD for) must be in the same AD Forest as the UAG server. If the user comes from a trusted AD Forest, the KCD will not work.

While designing your solution, you will have to gather a lot of requirements and understand the customer’s situation. Some requirements will force you into certain design topologies, and it is important to answer them at the beginning of the design process. There are at least three main questions that you have to answer when designing your UAG/ADFS access solution. The answers to these questions will direct you into a certain design topology or might require a combination.

The first question relates to password management. If you have a requirement to provide password management capabilities to remote users, -i.e. password change and notification of expiring password, you must use a UAG trunk that uses AD as the primary authentication provider. This type of trunk will authenticate you before providing access to any published applications. Access to claims based applications will be done via a secondary authentication to the back end published AD FS v2 server. This is the first topology that we discussed in the first part of this paper. Figure 1 shows this configuration.

Figure 1: UAG with One Trunk and dedicated AD FS in each Trunk

The second question relates to strong authentication, i.e. Smart Card based authentication. If there is a requirement to provide Strong Authentication, then your remote access solution must have topology #2, with UAG trunk configured for Smart Card authentication against the Active Directory and the AD FS server configured as an authentication provider for the claims based application. Anytime there is a requirement to use Smart Card authentication on the UAG portal, it will consume at least one AD FS Federation Service. Since we cannot use the same trunk to provide authentication via AD UserID/Password and Strong Authentication, the configuration will have at least two UAG trunks. Figure 2 shows this configuration.

Figure 2: UAG with Two Trunks and dedicated AD FS in each Trunk

The third question relates to the federation requirements with other companies. We need to identify if there is a federation requirement with external partners, specifically with IDP partners, where your company provides application resource for their use. If there is none, then our solution encompasses topology #1 and/or #2. If you must support federation as RP STS, then it complicates things. UAG trunks used for FBA or Smart Card authentication will consume their AD FS Federation Services, and it cannot be used by another trunk on the same UAG server.

We must implement yet another AD FS Federation Service on the internal network. If you need to satisfy all three requirements, you will need to have at least three UAG trunks, each with its own dedicated AD FS v2 server. Figure 3 shows this configuration.

Figure 3: UAG with Three Trunks and dedicated AD FS in each Trunk

As you see in Figure 3, this is not a simple solution anymore. While we can use the same UAG server to publish all of these services and all kinds of applications, we must implement three separate AD FS services. However, this is not the end of the complications. There are still some critical design decisions that you must make. What is the ultimate goal of this solution? Yes, the goal is to publish applications to the end users. And what type of applications are we trying to publish via UAG/ADFS configuration? We are trying to publish claims based applications. Let’s think for a moment about configuration requirements for claims-based application. The first and foremost requirement is that it must be configured with a trusted Security Token Service. It must be able to accept security tokens from trusted STS for user authentication.

How would we need to configure the claims-based application with multiple AD FS v2 servers and multiple UAG trunks? The first logical way to look at it is by creating trusts between the target application and each STS. As shown in Figure 4, in such configuration each trunk will have its own AD FS server which will be able to issue security tokens to the application. The problem with this approach resides with Home Realm Discovery. If we configure the application to trust multiple STSs, we have to make some type of determination at the application level of where the user must authenticate to get the valid security token. We are taking Home Realm Discovery out of the AD FS realm and trying to do it at the application level. While theoretically it is possible, the reality is that applications are not designed to do Home Realm Discovery. The underlying Windows Identity Foundation service must be extended to provide this functionality, which is not very easy to do and, in most situations, is not the best practice. The goal behind claims based authentication is to simplify authentication and simplify the application developer’s life, thus outsourcing authentication related Home Realm Discovery functions to the services designed for this purpose. The bottom line is that setting the application with multiple STSs is not recommended, and it is not the best practice.

Figure 4: Application with multiple RP-STS

The other common way to configure claims-based application is with one STS. Usually it will be designated as the Resource Provider role (RP-STS) and let RP-STS issue all security tokens for this application. RP-STS will be required to route user requests destined for other Identity providers. In our configuration, one of the AD FSv2 servers will be acting in this role. Which one should it be? The STS published via federated UAG trunk, (i.e. with UAG acting as AD FS proxy,) is the right choice for RP-STS. The configuration is shown in Figure 5.

Figure 5: Application with dedicated RP-STS

This is a complex solution, but if you must have at least two UAG trunks with support for claims-based applications, this is the only viable choice to publish them.

In the next post we will take a look at a specific real world example of how UAG and AD FS can be used to publish applications.

UAG and ADFS Better Together–Authentication via Azure ACS

2011-10-18T02:51:20Z

This post discussing how it is possible to publish applications to Internet based users who authenticate to the UAG via one of the Internet Cloud Identity Providers, such as LiveID, Google, Yahoo or Facebook. The Windows Azure ACS acts as IdP-STS in this configuration topology.

This is essentially the same as what we discussed in the previous configuration, where we published applications to partner organizations. The key difference here is that we do not actually have a specific individual organization. In this configuration, we are able to provide access to our applications to anyone who already has an identity at one of the big Cloud Identity providers – Microsoft LiveID, Google, Yahoo and Facebook. This accounts for millions of users.

The Microsoft Cloud development platform, Azure, provides this very unique capability via Azure Access Control Services. Azure ACS is configured to use these four identity providers as a potential authentication source. Very minimum configuration is required. Azure ACS must be configured as a trusted Identity provider with our internal RP-STS. From there on, the authentication is very similar to Federated WebSSO.

After the user tries to access the published application, he will be redirected to the RP-STS. Home Realm Discovery will be done at this point, and the user will be redirected to the Identity Provider, in this case Azure ACS. Depending on how Azure ACS is configured, it will redirect the user to one of the Cloud providers or it will give the user the option to choose one of them. The user will authenticate to the Cloud Identity provider and will be redirected back to Azure ACS, which, in turn, will create a SAML security token, provide it to the user, and from there on it will be posted back to RP-STS, transformed, and provided to the target application. Figure 1 shows the high level configuration for this topology.

Figure 1: Azure ACS in Federated WebSSO

UAG and ADFS Better Together–Publishing Applications to Partner Organizations

2011-10-02T15:02:13Z

In this scenario, our partner organization users access claims based applications published by our organization UAG servers. The partner users provide security tokens issued by the partner controlled Identity Provider to our AD FS v2 published by the UAG server. This configuration is the most common federated access scenario, and UAG works very nicely to make it all happen.

The ultimate goal of such configuration is to provide a SSO experience to the end user and never ask them for additional credentials or any type of questions. There are two main areas that must be properly configured to accommodate SSO. The first one is part of the partner organization configuration. Their IdP must be able to authenticate the user on their internal network via SSO. This is easily done if IdP is using AD FSv2. As part of the same AD Forest, it will authenticate internal users via Windows Integrated Authentication and will issue the required security tokens. The second part in this configuration is to configure Home Realm discovery. RP-STS residing on our network (woodgrovebank.com) is probably acting as IdP for internal users, or it might have more Federated trusts with other IdPs. The proper configuration of Home realm discovery is important in Federated configurations so that users are not confused where they need to authenticate and that they might not need to see other partners in your organization. Home realm discovery can be configured via multiple ways and is a topic of its own. We will cover it sometime in future updates to this paper or via a separate article.

Figure 1 shows the overall topology for federated application publishing. If you are familiar with all previous topologies, then you can see how this will work, as it is pretty much an extension on all the previous configurations. Let’s take a look via Figure 2 at the high level authentication flow.

Figure 1: Federated WebSSO Components

First, the remote user will try to access the application published via the UAG server. Since the application is configured to work over claims-based authentication, it will redirect the browser to its RP-STS.
RP-STS can be published on the same UAG trunk as our application. This trunk must not use internal AD for authentication. It must be configured as AD FS proxy trunk with RP-STS as the AD FS server behind it – i.e. it must be acting as a relying party. The user will contact RP-STS to get the security token for our target application. This is when Home Realm discovery takes place. If Home Realm Discovery is not configured to automatically redirect this user to his own IdP, then he/she will be prompted to choose his IdP from a list of configured trusted IdPs.
During this step, the browser is redirected to his IdP, and it will try to request a security token for RP-STS. IdP-STS and RP-STS have a trust relationship, and, based on the conditions of this relationship, the IdP-STS will issue a security token to the user.
This token will be posted back to the RP-STS, where it will be evaluated and based on the configured rules, and transformed into a new security token with a new set of claims suitable for consumption by the target application.
The token generated by the RP-STS is redirected back to the user computer, and then, in steps 6 and 7, this token is posted back to the target application. The application will make its authentication and authorization decisions based on the claims presented in the token.

Figure 2: Federated WebSSO Authentication Flow

This topology is an extension of the third topology we discussed in this paper, (Authentication to UAG Portal via Claims Based Authentication and accessing internal claims based application,) and all of the specific configuration related to the UAG and AD FS server are generally the same as in that configuration. The main differences are related to the more complicated Home Realm Discovery configuration and configuration of the partner IdP-STS.

UAG and AD FS are Better Together – Publishing Non-Claims Based Applications

2011-09-24T14:27:41Z

In article “UAG and AD FS are Better Together – UAG as AD FS Proxy” we explored how user authenticates to UAG portal via claims based authentication and then accesses claims based application published via UAG portal. But what if published application does not support claims based authentication, after all how many applications out there that do? Fortunately, UAG is capable to publish and provide SSO experience for non-claims based applications as well. The caveat here is that they must support Kerberos authentication. If you remember this “UAG and ADFS are Better Together– Strong Authentication” topology where we provided access with strong authentication, we configured KCD authentication between UAG and AD FS server. In this topology the configuration is slightly different but concept is the same. Instead of doing KCD between UAG and AD FS, we’ll need to configure KCD between UAG and the target application.

UAG is smart enough to transition from the claims based authentication and request Kerberos ticket from AD Domain Controller on behalf of the user. During application configuration you’ll need to specify what claim you’d like to use as a leading value to get the Kerberos ticket. UPN is a good choice. Also, the proper SPN must be configured in AD for the target application.

Figure 1 shows main aspects of this configuration and Figure 2 provides high level authentication steps of how this works. It is very similar to the previous configurations, just in slightly different order.

Figure 1

First, user must authenticate to the portal with SAML token, this is done via authentication to the backend AD FS server.
When user tries to access published application that was configured with Kerberos Authentication, the UAG server will contact AD Domain Controller and will get Kerberos Service ticket for the target application. It will use the claim value that was configured with this application in its request to Domain Controller.
Then UAG will send Kerberos ticket to the target application. Application will use the Kerberos ticket for authentication and authorization decision.
If authentication was successful target application will allow access to the end user.

Figure 2

This configuration has similar constraints as was discussed in topology with Smart Card authentication, they relate to the Kerberos constraints. In this configuration application servers must reside in the same Active Directory Domain as UAG server (obviously that means that UAG must belong to AD domain) and the user account must be in the same Active Directory Forest as UAG server as well. Also, there are requirements on the Domain and Forest Functional level, it must be at least at Windows 2003 level.

UAG and AD FS are Better Together – Strong Auth to Cloud Based Applications

2011-09-22T23:25:13Z

Today we will discuss a solution that provides the following functionality: You what to require your company external users to use strong AuthN when they access 3^rd party trusted claims based applications. These applications can be hosted in the Cloud or by Partner organization.

The description of this topology is a mouthful, but that is exactly what this topology provides to us. It is really an extension of the second topology with addition of federated Resource Provider components. Figure 1 shows this topology.

In many situations you want to allow your remote users to be able to access claims based applications published by your business partners. So the critical question is how do you want to authenticate your remote users against IDP STS? Business partner would usually have RP STS which will issue security tokens for application access. Your user identity does not come from RP site of the equation; it comes from your side. If you want to increase the security, and in the current day and age it is becoming a requirement, your remote users must use smart cards before they can gain access to the IDP STS and receive their initial security token.

First, remote user will try to access partner application which will redirect them via their RP STS back the IDP STS Federation Service. IDP STS external URL is published via UAG and it will require smart card authentication. User authenticates to UAG, receives their security token from internal IDP STS and redirects it back to RP STS and then gains access to the partner application.

Figure 1

Figure 2 shows authentication traffic to for this configuration.

Figure 2

First, remote user will try to access application published by the Partner organization or by the Cloud Application provider.
Application will redirect user browser to its own STS (RP-STS). RP-STS will need to perform a home realm discovery. At this time user will be automatically or manually redirected to his own IdP-STS.
Since in this situation, the IdP-STS is published via UAG on the a trunk that requires certificate authentication, the user will be prompted to authenticate with his Smart Card. The authentication will be done against his corporate AD.
When UAG authenticates the user, it will use Kerberos Constrained Delegation to authenticate to the IdP-STS, and those providing SSO experience to the user. IdP-STS will authenticate the user and will issue Security token for RP-STS.
User browser will receive the token from IdP-STS and post it to the RP-STS.
Finally, RP-STS will take token issued by IdP-STS, it will evaluate it content and based on its own rules, will create its own security token. Claims in this token might be the same as what was issued by IdP-STS or they can be transformed according to specific business rules. User browser will receive the final token from RP-STS and will post it to the target application. Application will authenticate the user and proceed with its logic.

As we can see, this configuration topology provides a powerful way to increase remote user security and it did not require any type of special modifications on the part of the Resource Provider organization. For all they care, the initial authentication by the end user was done via any type of authentication mechanism. It gives a powerful and flexible way to security managers to increase their organization security posture and the same time provide access to remote applications over which they have no direct control.

UAG and AD FS are Better Together - UAG as AD FS Proxy

2011-09-01T23:25:31Z

In previous topologies (1 and 2) we did not expose AD FS server to the outside users as primary form of authentication. This topology will do this. One of the benefits of using UAG server in combination with AD FS is that it can now act as gateway or proxy server to the internal AD FS server, in fact UAG can now be configured as the relying party with AD FS server and accept SAML token for user authentication.

Figure 1 shows topology with AD FS acting as main authentication directory and providing access to internal claims based applications.

Figure 1

With this configuration UAG trunk is configured to use AD FS for authentication, it passes you all the way to the AD FS server, which challenges you for credentials, in this case it will prompt to provide username and password. AD FS issues security token to the user and it is presented for authentication to the UAG server. UAG server grants access to the UAG portal based on the security token issued from the trusted IDP STS – our internal AD FS server. Figure 2 shows how UAG trunk and published applications configured with different authentication providers.

Figure 2

When user tries to open published application, the user will obtain a new security token from the IDP STS, specific to this application.

Figure 3 shows authentication traffic to access the UAG portal and Figure 9 shows how user will access published claims based applications via UAG portal.

Figure 3

The remote user attempts to access Forefront UAG portal. Since the UAG trunk is configured to use AD FS as its authentication provider, the Forefront UAG redirects the web browser request to the AD FS (IdP STS) server to authenticate the user. During this step, the IdP STS server might show the home realm discovery page to user (not shown in this diagram) on which he/she must choose the organization to which they belong; in this case, it would be Woodgrove Bank, but since this is a WebSSO configuration, the IDP STS will not show home realm discovery page. The IdP STS must authenticate the user. Depending on how it is configured, it might present user with AD FS Forms based authentication page or it might prompt with Windows authentication pop-up dialog box. The remote user provides credentials and authenticates using his/her own AD DS credentials.
After successful authentication IdP STS creates security token with claims and it is transferred to the user.
User is silently redirected and automatically authenticated to Forefront UAG using the security token created by the IdP STS server. User will see UAG portal with applications that this user is authorized to access. It is important to note, that authorization is done via claims and not via traditional windows security groups. In this configuration UAG did not authenticate the user against AD, it authenticated user solely based on the SAML token, and as such, the authorization decisions must be made based on the content of SAML token. Thankfully, Forefront UAG is smart enough to perform such authorization decisions.

After user authenticated to the portal he might decide to access published application, after all, why access the portal if not using applications?

Figure 4

The remote user attempts to access the published claims based application using claims-based authentication in one of two ways, listed below. Regardless of the mechanism, target application will redirect the user to its trusted Resource Provider STS, in our case it is IdP STS.
- By accessing the Forefront UAG portal and then clicking the published application (this is the follow up procedure to the previous diagram)
- Or by accessing the published application directly using the alternate access mapping name (if application was published that way). If this is the case, the preceding steps in the previous diagram might take place as well, but user will not see the UAG portal, he will be taken straight to the published application.
Forefront UAG redirects the web browser request to the IdP STS server to authenticate the user. Since user is already authenticated to IdP-STS when he authenticated to UAG portal, he will automatically re-authenticate to it with current session cookie.
IdP STS creates security token with claims for published application and it is transferred to the user.
User is silently redirected and automatically authenticated to the published site, after which the site appears.

By using UAG as the front end secure access point we are actually able to simplify AD FS infrastructure. In most situations, for Internet facing deployments, AD FS would deploy Federation Proxy server, which authenticates users on behalf of the internal AD FS server. With this configuration UAG server act as the front end gateway to the internal AD FS server and it is publishing AD FS authentication pipeline via its application publishing mechanism.

At this point it would be a good time to mention what type of UAG Portal features are not available if UAG trunk is configured as relying party to AD FS server. The first one is important to mention because it relates to the user password management. When UAG trunk is configured with AD authentication, it is capable to provide the following two important functions for our remote users:

Password expiration notification. This is configurable on the trunk usually with 7 days threshold. If user password is about to expire, UAG will notify the user about it and allow to change it to a new password.
Password change. After user authenticated to the UAG portal, he can always change password via this function. So if remote users are never come on site and they have no way to change their AD passwords via normal mechanism, then this is pretty much the only mechanism for self-password management.

With UAG trunk configured as relying party to AD FS, it never authenticates to AD. AD FS server authenticates user to AD and provides SAML token to UAG for authentication. UAG portal will never know if user password is about to expire and it is not capable to change user passwords because it is not configured with AD as authentication provider. Unfortunately, none of the password management functions provide via AD FS authentication, all it does, is authenticating the user. It will not notify the user about pending password expiration, nor does it provide the mechanism for password change. This is important limitation as it might affect overall design of your solution. If you must provide password management to your users, then you must publish UAG portal with AD as primary authentication provider.

There are other UAG features that are not available with AD FS authentication, here is a short list:

UAG supports only WS-Fed Passive profile
No Rich Applications publishing with AD FS authentication
Impact on Office Applications
Cannot publish applications installed on the AD FS 2.0 server
No HTTP to HTTPS redirection
No mobile device access on federated trunks

UAG and ADFS are Better Together– Strong Authentication

2011-08-26T00:34:41Z

In the previous post we looked at the most common UAG configuration, with user using username and password for authentication to UAG. In this post we are going to explorer the following configuration – user authenticates to UAG Portal via Certificate Based Authentication (Soft Certificate or Smart Card based certificate) and then access internal claims based application and other types of applications.

Smart Card authentication is becoming a major requirement in many industries. In Federal Government very soon it will be a mandatory authentication mechanism for internal and external logical application access.

AD FS configuration in this topology is very similar to previous topology, but with a few very critical differences. To enable Smart Card authentication, the UAG trunk is configured to require certificate authentication. During certificate authentication, the user will use a certificate from his smart card, it will be presented to the UAG server and UAG server will authenticate user based on the certificate content, usually it is done based on the value of Subject Alternative Name extension UPN value. UPN stands for Universal Principal Name, it is e-mail like value and it is enforced by Active Directory to be unique. UAG will read this value from user certificate and map it against Active Directory user account with the same value. All of this is done via Kerberos authentication and nowhere during this process has user provided his username or password.

Figure 1 shows classic design with Microsoft Active Directory (AD) acting as main authentication directory and providing access to the internal applications using Kerberos authentication and providing authentication to the IDP STS.

Figure 1

So how does user get security tokens from AD FS in this configuration? UAG must be able to authenticate to it on behalf of the user, but user never provided his username and password. It is done via Kerberos Constrained Delegation (KCD). UAG is configured to be able to impersonate authenticated user via KCD and request service ticket from AD and present it to the AD FS server on behalf of the user. AD FS will issue security token to the user and user will be able to authenticate to the claims based application the same way as it was done in the previous topology. Let’s review step-through process again, Figure 2 show us simplified authentication flow.

Figure 2

Remote employee goes to the Forefront UAG portal and authenticates against the AD DS server using Certificate based authentication (Smart Card). They will get access to the UAG portal with published applications based on their security profile.
When user tries to access claims based application, the application will redirect the web browser request to the AD FS v2 server for user to obtain a security token.
Depending on the configuration, the AD FS server might show the home realm discovery page to users on which they must choose the organization to which they belong; in this case, it would be Woodgrove Bank, but since this is a WebSSO configuration, the IDP STS will not show home realm discovery page.
The IDP STS will send back a HTML 401 response message for user to authenticate. Forefront UAG is able to provide a single sign-on (SSO) experience for the user by answering the 401 response with the Kerberos ticket acquired on behalf of the user (KCD).
The IDP STS server provides a security token (containing a set of claims) to the user.
The user is redirected to the application and the user’s security token is presented to the application and the application appears.

While this topology increases security of initial authentication, it does lead to some limitations on the back end authentication and limits Single Sign On experience. To provide seamless access to back end applications they must support Kerberos authentication. On top of that, application servers must reside in the same Active Directory Domain as UAG server (obviously that means that UAG must belong to AD domain) and the user account must be in the same Active Directory Forest as UAG server as well. Also, there are requirements on the Domain and Forest Functional level, it must be at least at Windows 2003 level. These requirements put some limitations on the Single Sing On experience. If one of the listed conditions is not satisfied and user tries to access published application, the KCD will not work and he/she will be prompted to provide credentials in the common form of domain\username and password.

Same as in previous topology, the AD FS server does not get exposed to the Internet and you can’t federate it with external partners as RP. This is purely for internal use only, WebSSO solution design.

UAG SP1 and AD FS v2 are Better Together–FBA and Claims

2011-08-22T14:00:08Z

In previous post I started with introduction for UAG and AD FS integrations scenarios. Today post will discuss the first topology - Authentication to UAG Portal via Forms Based Authentication and accessing internal claims based application and other types of applications.

Many companies want to provide rich application experience to its remote workforce and telecommuters. This is one of the most common configurations for WebSSO scenario where company needs to publish internal applications to its remote users while ensuring that application access is done via secure access mechanism and users are properly authenticated before accessing internal applications. One of the great advantages of using FBA on the UAG trunk is that it will allow us to access all kind of applications on the back end, as long as you can authenticate to them with the same AD credentials used during FBA. It can be NTLM authentication, it can be Kerberos Constrained Delegation or it even can be forms based authentication, UAG can do them all.

Figure 1 shows classic design with Microsoft Active Directory (AD) acting as main authentication directory and providing access to the internal applications using NTLM or Kerberos authentication and providing authentication to the IDP STS. IDP STS server is published on UAG as an application server and it can be authenticated to just like any other internal Web application.

Figure 1

With this configuration users authenticate to the UAG portal with their user name and password and then are able to access any type of application via Single Sing On experience. For Kerberos and NTLM based applications it is accomplished via application configuration just like it was done in the prior versions of UAG. For claims based applications, the UAG is configured with additional authentication provider – AD FS v2, which provides SAML security tokens for authenticated users and allows seamless access to the application. Figure 2 shows how two different applications published on the same UAG portal use different authentication providers. As shown, application that uses Windows Authentication is configured with the same authentication provider as the UAG Portal Trunk, so after user is authenticated to the UAG trunk he/she can gain access to the application without providing additional credentials, experiencing SSO.

Figure 2

For the claims based application it works slightly different. The UAG is configured with additional authentication provider pointing to the AD FS v2 server. The claims based application is configured to use this AD FS v2 authentication provider. So how SSO is accomplished in this configuration? After configuring application with AD FS v2 based authentication provider UAG will publish another application under the application list. To accomplish SSO, you’ll need to open that application and under authentication tab configure SSO with the same authentication provider as the main UAG trunk (under which this app is published), in this case it is AD. When user decides to access claims based application, it will first authenticate to the AD FS v2 server by using AD credentials, obtain a security token and then present this token to the application. Figure 3 shows simplified authentication flow to the claims based application via UAG.

Figure 3

To access UAG Portal external users will be required to provide Username/password via Forms Based Authentication.
UAG will authenticate user against Active Directory.
After authenticating to UAG they will be presented with applications based on their security profile. It will be presented via UAG portal.
When user tries to access claims based application, the application will redirect the web browser request to the AD FS v2 server for user to obtain a security token.
Depending on the configuration, the AD FS server might show the home realm discovery page to users on which they must choose the organization to which they belong; in this case, it would be Woodgrove Bank, but since this is a WebSSO configuration, the IDP STS will not show home realm discovery page.
The IDP STS will send back a HTML 401 response message for user to authenticate. Forefront UAG is able to provide a single sign-on (SSO) experience for the user by answering the 401 response with the credentials previously entered by the user.
The IDP STS server provides a security token (containing a set of claims) to the user.
The user is redirected to the application and the user’s security token is presented to the application and the application opens in the user browser.

In this topology, the AD FS server does not get exposed to the Internet and you can’t federate it with external partners as RP. This is purely for internal use only, WebSSO solution design.

Next post will discuss the next topology - Authentication to UAG Portal via Certificate Based Authentication (Soft Certificate or Smart Card based certificate) and accessing internal claims based application and other types of applications.

UAG SP1 and AD FS v2 are Better Together–Introduction

2011-08-21T16:04:56Z

A few weeks ago I started working on a white paper about UAG SP1 and AD FS v2 configuration topologies and sample complex design based on those topologies. I’m still working on it, but I decided to publish different parts of it for folks to see and potentially get some feedback about it as well.

Today is the introduction time.

Unified Access Gateway (UAG) SP1 has introduced support for the AD FS v2. Now it is possible to publish claims based applications via UAG and provide secure access to AD FS servers by using one of many different configuration topologies supported by these products. This paper explains how to design solution by using UAG and AD FS v2, what type of critical requirements will dictate specific configuration and how to get around some of known limitations. It is assumed that reader has basic knowledge of UAG technology and AD FS technology, as this paper will build on that knowledge and introduce more advanced concepts of UAG and AD FS integration.

There are four main topologies that you can choose for AD FS WebSSO design and they are largely depend on the authentication requirements from the Internet to the UAG server or AD FS server and authentication requirements to the published application. The main topologies are as following:

Authentication to UAG Portal via Forms Based Authentication and accessing internal claims based applications and other types of applications.
Authentication to UAG Portal via Certificate Based Authentication (Soft Certificate or Smart Card based certificate) and accessing internal claims based applications and other types of applications.
Authentication to UAG Portal via Claims Based Authentication and accessing internal claims based applications.
Authentication to UAG Portal via Claims Based Authentication and accessing internal non claims based applications.

Of course, the WebSSO configuration can be extended to the Federated WebSSO configurations, where customers will be accessing resources published by your company UAG or where your company might require authentication against UAG before accessing resources published by your partner company. The following three topologies are extensions of the last three main topologies:

Require your company external users to use strong AuthN when they access 3^rd party trusted claims based applications. This is an extension of the second topology in the previous list.
Cloud based authentication or partner based authentication. In this scenario, customers access claims based applications published by UAG server and provide security tokens issued by the Cloud Based Identity Provider or Partner company identity provider to AD FS v2 published by the UAG server. This is an extension of the third topology in the previous list.
Customers accessing non claims based applications published by UAG server by providing security tokens to AD FS v2 published by the UAG server. This is an extension of the fourth topology in the previous list.

There is another potential design topology which existed before UAG SP1. It is always possible to just publish internal AD FS v2 server via UAG server as a web app and expose authentication against STS Proxy FBA or straight to the actual AD FS server FBA or Certificate based authentication. This type of configuration does not utilize new advanced functionality introduced in UAG SP1 and we are not planning to review it here or use it as potential design topology.

The rest of the document is divided into two parts:

Part 1 – Provides detailed review of each topology. Before looking at potential design choices for potential customer environment we must understand how each topology works, what type requirements it has and any type of limitations.

Part 2 – Provides a sample design of UAG and AD FS solution. Powered by the knowledge of configuration options we’ll look how to fit each topology or a combination of topologies to different customer situations.

WIF Extension for SAML 2.0 Protocol Community Technology Preview!

2011-05-16T16:57:36Z

Today Microsoft announced availability of the WIF Extension for SAML 2.0 Protocol Community Technology Preview. Check this blog post for more information:

http://blogs.msdn.com/b/card/archive/2011/05/16/announcing-the-wif-extension-for-saml-2-0-protocol-community-technology-preview.aspx

Secure Application Access by using AD FS and UAG – Strong Authentication

2011-02-21T23:42:23Z

In the last two posts on this subject I showed to you how to use UAG with Forms Based Authentication and as ADFS Proxy. Todays demonstration shows how to use it with Strong Authentication – Certificate Authentication. The topology in this configuration is very similar to the FBA topology, but it requires additional configuration on the UAG to require certificate authentication and we have to utilize Kerberos Constrained Delegation to access ADFS server. KCD is required because when user authenticates to the UAG portal, he never provides his UserID/Password, so if we want to have SSO then UAG must be able to impersonate user by using KCD, and provide Kerberos ticket on the behalf of the user to the AD FS server.

This demonstration was created to satisfy the following requirements for our fictitious Woodgrove Bank Corp:

Woodgrove Bank must provide secure access to documents on its Extranet SharePoint site to remote employees.
SharePoint site was designed to accept Claims based authentication.
Remote employees must use Smart Cards for accessing the site (certificate authentication).
Limit access to client computers that do not meet the company policy.

You can also watch this demo from my other blog at http://CloudIdentityBlog.com

As always, for best user experience please watch this demo in Full screen and enable HD. Let me know if you have any questions.

Microsoft U-Prove Community Technology Preview R2 Released

2011-02-18T13:47:51Z

In case you missed, a few days ago Microsoft released U-Prove Community Technology Preview R2, you can get the official page with more information about it and related downloads: https://connect.microsoft.com/site1188

At the time of this release it was also announced that Windows Card Space 2.0 will no longer ship. Here is the link to this announcement: http://blogs.msdn.com/b/card/archive/2011/02/15/beyond-windows-cardspace.aspx

Secure Application Access by using AD FS and UAG – UAG acting as ADFS Proxy Topology

2011-02-17T00:41:17Z

In the previous post I showed to you how UAG can be used with ADFS to publish Claims aware application and provide single sign-on into such applications along with traditional applications which require UserID/password. In that demonstration UAG was configured with Form Based Authentication (FBA) and user was authenticating to UAG before they could get access to actual applications.

Today’s demonstration shows a different UAG/ADFS topology, with UAG configured as ADFS proxy is exposes ADFS server for authentication and then it can provide you with UAG portal or directly route to the target application.

This demonstration was created to satisfy the following requirements for our fictitious Woodgrove Bank Corp:

Woodgrove Bank must provide secure access to documents on its Extranet SharePoint site to remote employees.
SharePoint site was designed to accept Claims based authentication.
Woodgrove Bank plans to allow access to SharePoint site to its partners using Claims based Federation technologies.
Limit access to client computers that do not meet the company policy.

You can also watch this demo on my blog at http://CloudIdentityBlog.com

As always, for best user experience please watch this demo in Full screen and enable HD. Let me know if you have any questions.

Secure Application Access with ADFS and UAG – UAG providing FBA

2011-02-15T20:52:38Z

More and more companies wish to provide secure access to their applications from external locations. At the same time, many of these applications starting to adopt new authentication technologies, for example, like Claims based authentication. The following demonstration shows how companies can use Forefront UAG 2010 and AD FS 2.0 to provide secure access to different types of internal applications, all published via single unified portal and providing Single Sign-On experience to their users.

The solution in this demonstration shows UAG implemented to use FBA as main authentication mechanism and it ability to access Claims based applications.

This solution created to satisfy the following requirements for our fictitious Woodgrove Bank corporation:

Woodgrove Bank must provide secure access to documents on its Extranet SharePoint site to remote employees. It also wants to provide access to other internal resources.
SharePoint site was designed to accept Claims based authentication.
Other resources require standard UserID/password combination.
Woodgrove Bank employees should have SSO experience when accessing documents on Woodgrove Bank Extranet SharePoint site and other resources.
Limit access to client computers that do not meet the company policy.

You can also watch this demo and other demos from my blog at http://CloudIdentityBlog.com

For best viewing experience please watch it in Full screen with High Definition ON. Let me know if you have any questions.

Microsoft Business Ready Security–Secure Collaboration for Roaming Users with Unified Access Gateway

2011-02-08T13:40:38Z

Did you know that you can download virtual labs to your own host system and test Microsoft Business Ready Security (BRS) solutions? It is available to anyone on the Internet. Go check it out for yourself: http://go.microsoft.com/fwlink/?LinkId=190269

If for some reason you can not download those labs, don’t have time to set it all up , don’t have capable hardware/OS to run it or you need extra explanation on how these solutions work then you are in the right place. Here is one of the solutions that are enabled by Microsoft BRS.

The following demo shows solution created to satisfy the following business and technical requirements:

Provide access to internal network to roaming users from the Internet.
Limit access to client computers that do not meet the company policy.

You can also watch this demo from my blog at http://CloudIdentityBlog.com

For best viewing experience please watch it in Full screen with High Definition ON. Let me know if you have any questions.

Microsoft Business Ready Security–Secure Collaboration with Partners by using AD FS

2011-02-07T20:50:24Z

The following demo shows solution created to satisfy the following business and technical requirements:

Woodgrove Bank and TreyEngineering are working on a joint project.
Woodgrove Bank must provide access to some documents on its Extranet SharePoint site to employees of TreyEngineering who was assigned to this project.
Woodgrove Bank will not create accounts for TreyEngineering employees in its user domain.
TreyEngineering employees should have SSO experience when accessing documents on Woodgrove Bank Extranet SharePoint site.
SharePoint must be protected from documents with known viruses.

You can also watch this demonstration from my blog at http://CloudIdentityBlog.com

For best viewing experience please watch it in Full screen with High Definition ON. Let me know if you have any questions.

Implementing FIM 2010 Certificate Management (Part 4)

2011-02-04T05:06:00Z

This is the fourth and final installment in a four part series showing how to implement FIM 2010 Certificate Management solution. You can watch the previous three parts by going to each presentation:

If you wonder what is the final result of this specific implementation then please watch demonstration showing how to do manual certificate enrollment via FIM 2010 CM.

Todays demonstration covers the following tasks:

Configure Service Connection Point Permissions
Delegate Profile Template Permissions
Configure Permissions on Certificate Sponsor
Create SSL Profile Template
Configure Profile Details
Configure Enroll Policy
Configure Revoke Policy
Define Permissions on the SSL Profile Template
Request Certificate for FIM CM Portal
Fixing FIM 2010 CM Configuration (AES and CSP)
Request Certificate again
Installation of issued Certificate on the FIM 2010 CM
Set SPN for the new URL
Final test of the new Portal

You can also watch this demonstration from my blog at http://CloudIdentityBlog.com

For better experience please watch it in Full screen and enable HD.