Single SIgn-on, SSO for short, is an an attractive but elusive thing. Log into to your dekstop PC and be signed in to all your other applications – be they local or remote.  Your cloud provided business applications: Office 365, Amazon Web Services. Your online news site: The Economist etc.  Without having to enter username and password again. This does sound attractive.

So much so that some have found it expedient to sell something as SSO which strictly speaking is only single-login. There are tools for propagating usernames and synchronizing users stores. But they don’t log you in when you need to. You still have to enter your username and password. This is not SSO, merely single provisioning. Helpful, but still a nuisance with repeated entering of login information. What we want is true Single Sign-on.

All those login names and passwords. If you consistently use only your email address (and always the same one) as user name. Perhaps even, incautiously use the same password everywhere. There is sheer nuisance of it all.  Which in and of it self is enough to make people use the same password everywhere. This makes corporate systems vulnerable. If someone has used a password in an external system and this system is compromised, and the password revealed. Well, the attacker now has a very good password first guess for further attacks. So SSO which obviates the practical need to unified login information, but particularly the re-use of passwords, is much needed.

Such solutions do exists. User federation happen in many ways. You can now sing in to many applications simply by using your login to Facebook. Microsoft provides ADFS which allows SSO to many applications in the Windows sphere, most particularly Office 365, from you Windows desktop. This is what we want SSO from the desktop, but without the limitations of ADFS. We want to be able to login anywhere, not just to places that have been configured for ADFS.

For the purposes of this article I’ll limit myself to Sing-on part – the actual loging in. This presupposes the existence of an account in the target system, leaving just-in-time-provisioning aside (but see here for exploration on the topic of account-less access) which I will assume is already in place. There are any number of ways to provision accounts. and to the extent that this is a one-time thing, not really much of a bother for the end user.

Recently I had occasion to explore the identity management tools from Okta (www.okta.com) which promised to deliver on this tall order.

 

What follows is not a complete “cook book.” but it will include all the steps I went through , in order, to put in place true desktop SSO using the Okta framework. Both for an application that accepts SAML based federated login: Here I picked Amazon Web Services, AWS, for the demonstration. And one that just has a username/password login: Here I selected The Economist.

 

 

The Okta SSO architecture contain the following components:

The user’s Windows desktop PC.

The Windows domain controller, DC, to which it subscribes,

The Okta server at https://<your domain>.okta.com, When your organization subscribed to Okta, this is set up for you with a sub-domain name of  your choosing. There is also an administration domain name of the form <yourdomain>-admin,okta.com,

The user’s browser,The SSO is only for web based applications. A browser is always employed in their access.

The plugin provided by Okta for that browser. The supported browsers are Internet Explorer, Mozilla Firefox, Google Chrome and Safari. This plugin is essential for populating login fields for non-SAML based logins.

Okta agent for the Windows DC. This agent must be installed somewhere in you corporate infrastructure on a Windows server with direct access to the DC. In this case it was installed directly on the DC.

Okta’s Integrated Windows Authentication, IWA, login application. This is a web applications that runs on an IIS instance in your corporate Windows server infrastructure. When your browser is configured to send Windows Authentication information to configured list of web domains, this application is on that list. This is the main way the ID with which you are authenticated to your desktop is collected by the Okta infrastructure. In this case it was installed directly on the DC.

 

First subscribe to Okta and login to the Okta admin interface. Okta has two free subscription options: A developers license with a limit on the number of different applications that can be connected to it, but last forever. Or a regular, “enterprise”, license with no limits on the applications but which is good (read: free) for only a 30-day trial period. In this example I have selected the “regular” one since the time limit is of no concern here.

After signup, an confirmation email is sent to you with the relevant login details.

Login to your corporate Okta page as the admin and go on to the administration interface (the “admin” button) From Setting- Download download the following:

The plugin for the browser(s) you are using. Keep the plugin install files for later installation in other browsers.

The AD agent installer.

SSO IWA Web App Installer

We won’t use the password synch agent in this exercise.

 

Create a serviceaccount for the AD Agent on the DC. I called it “OktaService” and placed in the root container in my “cloudworks” (dc=cloudworks,dc=demo) domain. This user must be granted permissions to log on as a service and as a batchjob. Plus the, for service accounts usual do not change at first logon and password never expires options.

Run the AD Agent installer (OktaADAgentSetup-3.2.1.exe) on a windows Server with access to the DC. I used Windows 2012 R2 which also hosts the DC, and this proved an excellent choice.

The installer ask for

Install path: accept defult

Domain: cloudwork.demo

Okta AD Agent service account: this will be used to access AD and is the one created earlier: “OktaService@cloudworks.demo” / password

Proxy Configuration: no

Register Okta AD Agent: The agent will be connected to the Okta infrastructure. specify you domain here. https.//cloudworks.okta.no  which means just ticking “Production” and entering “cloudwork” in the subdomain field.

A browser window opens and a HTTP connection is being made to Okta.  You are presnted wit ha login window where you specify the administrator login details for your corporate Okta account established above.

A question is presented: Okta AD Agent is requesting permission to access the Okta API. Click “Allow Access”.

Install the IWA application. This is a web application that we will install on an instance of IIS (version 8.5.9600 running locally on the DC. But you can install the IWA application on any existing instance of IIS you have handy.

The IWA installer request the details of the service account the IWA applicaiton will need to run (specifically the application pool set up in the IIS) I reused OktaService account from above.

Specify the okta subdomain to be used: “cloudworks”, in this example. Once again a browser windows is openen and a login windows to Okta is presented. Enter the administration login as per above.  “Okta Desktop SSO Agent is requesting permission to: access the entire Okta API” ? Click “Allow Access”.

Go to the IIS manager where the IWA is installed and make sure it really is running. It should have an Application pool names OktaIWA with the identity specified with the installer. One of the installed Sites should be IWA. Under it in the web tree you should see the directories: bin, certificate, conftemplate, docs, img, installerlog and tools.

Log in to the Okta admin console at https://<your subdomain>.okta.com which is https://cloudworks.okta.com

This login works on Internet Explorer but not on Firefox.

 

 

 

 

 

 

 

 

The message states that I do not have any applications. Which makes sense since I have not configured any yet. I logged in as the administrator so the little triangle next to my name is a drop-down menu with “Admin” on it. Selecting this brings me to the administration interface for our Okta implementation. This URL: https://cloudworks-admin.okta.com/admin/dashboard. which I will use directly from now on.