how to address complex WebSSO scenarios with UAG and customization

This year, I will be at Tech Ready - a Microsoft internal event - giving a few sessions about Unified Access Gateway.

One of them will be about Web Single Sign on, especially how UAG – using the internal engines and customization – can address very complex scenarios.

Idea of this post is to share with you one of the demo I will do that show how UAG can do that.

The challenge

The idea of this demo is in fact find an answer to a very common situation. A customer has many web applications in the company, some of them are using Form authentication and others integrated (NTLM/Kerberos), … but more important, some of these applications are not using at all AD as the authentication repository. So you may have multiple user repositories inside the company, so a physical user (a user object in AD) can be linked to many “users”, one for each application. This is a 1 to many scenario.

A good example of this situation is this:

So here is the challenge. How can I provide WebSSO experience to the users, especially because the credentials will not be the same across all the applications (scenario 2 and 3) ? What if a user has multiple identities in 1 application (scenario 3)?

Basics of “UAG” SSO

The WebSSO approach with UAG will be to put the machine between the clients and the applications – acting as an advanced ReverseProxy. Among all these advanced features, UAG will provide a strong “web single sign on engine”. Because all the traffic goes back and forth through UAG, this engine will take care of “authentication requests”, and will react on behalf of the users, providing the Web SSO experience.

Scenario 1: replay the “border authentication”, no matter if it is FORM or INTEGRATED

Cool thing on this scenario is that you have nothing to do but to go in the UAG console, and check a few options. UAG will then “re-use” the border authentication information (in fact the border login and password) in order to provide SSO experience towards all the applications linked to the same repository.

In this example, all “AD related” applications will benefit of this WebSSO engine without any effort. In the configuration, you have to tell UAG which repository to use, how to handle authentication requests, … job is done.

Here is a screenshots that shows the different options in the GUI. You can see that “use single… “ check box is checked (means SSO turned on), repository is “woodgrove bank AD” which is the same as the border authentication, and we are ok handle FORM or 401 (integrated) authentication requests from applications.

Figure 1 - how to turn SSO on for each application, UAG console

The “use Kerberos delegation for single sign-on” is used for KCD, which is the ability for UAG to ask AD a Kerberos ticket “on behalf of the user”, and send it back to the application (integrated).

Let’s see now how we can extend the options in the GUI, to cover more scenarios.

Scenario 2: gathering credentials from a “safe” (centralized database where all credentials are)

The challenge here is very complex. How can I provide Web SSO towards a web application when I (UAG acting as a reverse proxy) don’t know at all the login and password to use?

First option is to ask the user these credentials but that is no SSO right?

The second option is to store these authentication elements in a secured place (let’s call it provisioning phase), and ask then to UAG to “load” these information (the load phase) in the user session. Finally, when user clicks an application, the WebSSO will locate the credentials in the session, and will do SSO (the SSO phase).

To do this “Load” job, you will use a bit UAG customization, which means create our “own” visual basic code (our own intelligence) that executes exactly the scenario we want to implement.

You can see below an basic example of code where I use the UAG API to load identities. The UAG API name is AddSessionUser.

It adds in memory “for the user session” (g_cookie is the session cookie for this user), an identity (login and password, second and third parameters) for a specific repository (The last parameter).

Figure 2 - Basic sample of UAG API to load an identity

Here you can see that I loaded in memory an identity for a “SAP” repository, and also 2 identities for a “JDE” one.

Of course it is hard coded here, so let’s add some more code to “gather” that information from a “safe” area.

Important: In this article I propose an approach that you have to consider as a “sample”, not a code ready to go on production. I mean here that this scenario is not a built-in features in UAG, so we need to go through a “professional services” (architecture) process to validate the best options for the customer, in terms of performance, security, provisioning. But on the other hand, it provides a very easy and quick demo of how customization can reach the limit of a business need, and at the end of the day address this customer scenario.

For this demo, I will use AD to store these identities, in one of the properties of the user account named “INFO”. For “DEMO” I can keep the info in clear, but for LAB or PRE-PRODUCTION we need of course to cypher this information (the sample script I propose support both scenarios.. and can of course be enhanced with public/private key approach).

So, here is the demo I can propose you:

· Store ALL credentials of the user in the “info” property of his user Account (you can use “users and computers MMC”).

· UAG will load these identities in a phase called “post connect” (after authentication is successful). To do so it will first read this “info” field with LDAP, and then call the UAG API to load them in session

· UAG “Web SSO” engine will do his job.

Here is how you can implement this scenario in AD.

This user has 3 identities, 1 line per identity.. and it contains the elements we need to call the API.

Figure 3 - Users and Computers MMC, 3 identities.. in clear or encrypted

On the server-side, we added some VB script code in the “post connect” hook.

First part this code is used to do an LDAP Search in AD, in order to read the info field :

Figure 4 - LDAP search

As you can see this is very standard LDAP search code. I hard coded the “administrator” account for demo purpose, but in reality you should not have ‘cn=administrator’ but more something like ‘cn=”+user_name+”’, since user_name is an internal UAG variable which contains the border authentication user name.

Second phase will be the decryption phase (if needed):

This code works fine for POC and demo, but is not ready to go on production. During professional services phase, you will of course do better, especially use pub/priv cypher

At the end of this code, we have the “text” that contains the identities.

In this script I will “split” the data gathered from the info field, and inject them with the UAG API in the SSO engine.

Now the scenario is ready on both AD (acting as the repository) and UAG side.

If you connect with the user, these identities will be loader. You can use the UAG application name “web Monitor” to verify that. Select the user’s connection and you will see the identities.

Figure 6 - UAG web monitor, session details, showing identities

As you can see here, user authenticated using the “woodgrove bank Active Directory” (border authentication), and our script preloaded ONE identity for SAP, and TWO identities for JDE.

As a result of that, if user clicks an application linked to either “SAP” or “JDE” repository, the UAG will use these credentials, and provide SSO.

Scenario 3 : The case of the JDE repository

As you have noticed, we loaded 2 identities for this “JDE” repository. The typical scenario is a finance person, who has many application accounts in the finance system since he is in charge of accountancy for multiple companies, so one login name = 1 company. In this example, our “AD administrator” has 2 JDE identities: User98 or User99.

My repository is called JDE, since I did the same scenario for a big company using JD Edwards, where one of the users had ’70 JDE accounts’ in the system. Challenging ?

So what UAG will bring in this scenario, is the ability to pre-load ALL the identities and when user click the application (since UAG sees that X identities are linked to this application), the user will be prompted to select (a radio button list) the appropriate identity.

Here is what you get when you click an application linked to a repository which has multiple identities loaded :

Figure 7 - WebSSO when X identities

Conclusion

As you can see by default – without any code – UAG’s SSO engine can provide WebSSO for application, and can cover a lot of scenarios.

If you reach the limits (here you can’t invent a login/password you don’t know), and if you can’t user Kerberos Constrained Delegation (KCD), you can use UAG API to extend the capabilities, and reach the business scenario.