Mobile Single Sign-On

The other day, we were at customer's site and the discussion was on Mobile Single Sign-On (MSSO). This customer will be launching a few mobile applications and he would like users to have the convenience of not having to sign-on every time a mobile application is launched.

Traditional Mobile Single Sign-On

The traditional method of achieving MSSO is to develop yet another mobile application to act as a SSO Wallet and the SSO Wallet will act as the bridge between the various mobile applications and the Identity Provider (IdP). 

I'm using Gluu Server as an example now. But IdP can be any federation solution. 

Modern Mobile Single Sign-On

In iOS and Android, simple MSSO solutions are provided by tapping on the Cookie concept in browser.

For iOS, SFSafariViewController is recommended, while in Android, Chrome Custom Tabs is suggested. 

Quite convenient to implement.

Of course, we did discuss about a scenario whereby Chrome browser is not installed, then MSSO on Android will fail. This can be overcome by user education.


.

Gluu AD/LDAP Synchronization - Part IV

When configuring AD/LDAP Synchronization (Cache Refresh), it is very important to enable "Keep external persons".

Why? Because the administrator "uid=admin" resides in the same organization unit (ou=people) as the imported users from external AD/LDAP.

Be careful.

.

Gluu AD/LDAP Synchronization - Part III

After AD Synchronization (Cache Refresh) was configured, I realized the total number of people imported exceeded the number of actual users we had in office. 

There is a way to filter off the unnecessary users from Microsoft Active Directory. If an AD user is a staff, we will tag this user as a member of "Azlabs Staff" AD Group.

Then we can re-configure Cache Refresh in Gluu Server again -- "Customer Backend Key/Attributes". (Yes, I dislike this tab title. Very confusing.)

Do remember Custom LDAP filter has to be a proper LDAP Query. As such, the memberOf value has to be a full DN. e.g. cn=Azlabs Staff,cn=users, dc ....

Wait for the next Cache Refresh to kick in.

Done.

.

Gluu AD/LDAP Synchronization - Part II

This is a step-by-step configuration guide to configure AD Synchronization (Cache Refresh) in Gluu Server. 

There is a documentation available here, but I find it too generic and at times, confusing. Far too wordy with little graphical illustrations.

Step 1: Source Backend LDAP Servers

Click on "Add source LDAP server"

Fill in the detail for the backend MS AD server

Appears on top-right of screen when "Test LDAP Connection" is clicked

Step 2: Customer Backend Key/Attributes

( This is the screen that I have the most opinion on. Why use "Customer", not "Source"? Why "Source" Attribute? How about the rest? They are not from "Source"? It's not consistent.)

Take note that the above should reflect how a Person object is to be fetched from MS AD 

Step 3: Cache Refresh

Make sure "Keep external persons" is enabled

As per documented, "This will allow your default user 'admin' to log into Gluu Server after initial Cache Refresh iteration. If you do not enable 'Keep External Person', your 'admin' user including all other test users will be gone after first Cache Refresh iteration."

Left column refers to Source; Right column refers to Destination

Make sure "Cache Refresh" is enabled

Step 4: Manage LDAP Authentication

Remember this diagram from previous post?

What we have done so far is for (2) to work.


For (3) to work, we need to navigate to Configuration > Manage Authentication. Scroll to the bottom of the page, click on "Add source LDAP server".

Add MS AD detail. Click "Test LDAP Connection" to ensure connection is OK

Done.

.

Gluu AD/LDAP Synchronization

In Gluu Server, there is a concept called AD/LDAP Synchronization.

AD/LDAP Synchronization, a.k.a. Cache Refresh, is the process of connecting one or more existing backend LDAP servers, like Microsoft Active Directory, with the Gluu Server's local LDAP server. Syncing people and attributes from a backend server speeds up authentication transactions. It is possible to perform attribute transformations, changing the name of attributes, or even using an interception script to change the values. Transformations are stored in the Gluu LDAP service.

How does authentication take place?

Because there is no password stored in the "local copy" of the Gluu LDAP, authentication has to take place on the actual Microsoft Active Directory instead.

1. User attempts to authenticate with Gluu Server
2. Gluu Server searches if the user exists in "local copy" of the Gluu LDAP
3. If yes, Gluu Server will authenticate against the actual MS AD server with the username and password


Slightly different architecture from other SSO products.


.

No SSO

Many times during SSO presales or tender presentations, we will be asked the same question again and again - "What if the SSO infrastructure goes down?"

Ting ... Ting ...

Most of us who have been in this field long enough will respond that high-availability has to be in place for such a critical infrastructure. One could go further to elaborate about the the reliability of cloud infrastructure like AWS scale-out, AWS availability zone failover, VM Fault Tolerance etc...

Nothing beats application building its own local authentication as a last option.

It's a fact.

.

Implementing Web Policy Agent on with AWS - Part II

We know a Policy Server consists of 2 very important components - Authentication and Authorization.

The following diagram is a typical deployment diagram of a traditional SSO architecture with a Web Policy Agent deployed on a web server, that communicates with a Policy Server on the backend.  

How do we achieve the same in AWS world?

1. Authentication will be performed at the Login Page which integrates tightly with Amazon Cognito. (By the way, the pricing for Cognito is quite attractive!)

2. Authorization will be performed at the "Policy Server", which I discussed in my previous post.

In fact, we can do better than that for the Authorization.

In the modern world, API is everywhere. We can have a API Gateway that exposes a isAuthorized API. The "Policy Agent" will "ask" the API Gateway if a user is authorized or not.

In additional, we can implement fine-grained authorization by building entitlement microservices.

As long as we introduce a clean interface for the entitlement microservice, customers can own this piece of work to implement their own business logic and plug-in to the authorization framework anytime. 

.

Implementing Web Policy Agent on with AWS

In my previous post on Single Sign-On with AWS Cognito, my team successfully demo a way to implement Cross-Domain Single Sign-On with AWS Cognito. 

There are many ways to implement SSO. For a start, since Azlabs is very familiar with how Single Sign-On works, the team chose to minimize the changes required on existing applications that were protected by traditional web policy agents. 

The assumption is that if any of our customers were to port over to AWS, there is minimal impact during migration. 

How can we achieve this? 

Let's take a look at how traditional SSO works. 

1. There is a Policy Server where A+A (Authentication & Authorization) takes place

2. There is a Web Server where a web application (Web Resource) is deployed

3. There is a Web Policy Agent sitting on the same Web Server intercepting traffic to the Web Resource. 

4. The Web Policy Agent queries the Policy Server for A+A decisions.

Illustration 1

Illustration 2

Let's build a "Policy Agent + Policy Server" concept in AWS!

.

Cross-Domain Single Sign-On with AWS Cognito

We have been exploring how to implement cross-domain single sign-on (CDSSO) on AWS platform for a while.

The underlying user store is using Amazon Cognito User Pools. It provide a secure user directory that scales to hundreds of millions of users.

Using Cognito out of the box, Amazon Cognito lets you add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily. Amazon Cognito scales to millions of users and supports sign-in with social identity providers, such as Facebook, Google, and Amazon, and enterprise identity providers via SAML 2.0.

That's it. In fact, it's mostly mobile-centric and support single domain for single sign-on.

To support CDSSO, we need more components from the AWS family to come into play - AWS Fargate acting as Session Validator, AWS Lambda acting as Cookie Generator/Destroyer  and AWS RDS acting as Session Store.

We demo to a customer yesterday and they were impressed.

To speed up the authentication process, Amazon ElastiCache can be used to replace or complement AWS RDS. That would be our next demo.


.

SSO Migration in 10 (+3) weeks ... People matters!

I have a long time SSO customer who came back to me after 6 months "ditching" us. Well, the actual fact was a new VP came in and we did not get along well. Anyway, he couldn't deliver after 6 long months and he was out of the game. The old VP called me immediately after she was reassigned  with the SSO infrastructure.

I'm very familiar with their environment and even though there is a lot of customization, I promised the whole migration will only take 10 weeks. Yes, a major jump in software version. A lot of code rewrites. A lot of Java code decompilation as the software has gone closed-source. It was real fun!

I brought in my best team. And we are going live this coming Sunday! (Ok, customer requested to delay go-live for another 3 weeks as there is 1 site that customer would not want to migrate to the new platform. Thus communication with their end-customers is required to shut down that site.)

Last mile and we are talking about Cut-Over Plan yesterday.

I joined in the discussion. Towards the end of the discussion, customer looked at me and asked me if I have any comment. My only request was: "Give me the same set of people who had performed the dry-run weeks before."

It is going to be a real long night this Sunday and a lot of eyes are on the whole team. I told the manager of the application teams not to assign people based on availability (you know, as this is a midnight job, the seniors will always find excuses not to be involved), but based on experience and capability. Don't give someone who has no idea what is going on.

People matters!

CA SiteMinder - Drawbacks

Common to all Single Sign-On products that have been out there in the market for the past 10 years, most provide agent-based solutions. 

Agent-based solutions have been working like a charm. But they have been a pain operationally.

1. Cost of Agent management grows as the deployment grows
2. Application owners and developers concerned about time to deploy
3. Need to coordinate with application owners for upgrades

These are very true points from our experience deploying multiple large-scale SSO solutions in the past.

One of the workaround is not to deploy agent on every application server. Instead, deploy a Reverse Proxy farm (RP farm). This is a centrally controlled farm with Apache HTTPd server with agents deployed.

Of course, bad points aside, there are benefits to having agent-based solutions.

1. Broad application coverage
2. Security
3. Scalability

.

Federation vs Web Access Management (WAM)

This question has been asked repeatedly over the years. I came across this link while I was searching for OpenID Connect feature in CA SSO 12.7.

Federation has the following advantages: 

• Many applications can handle federation directly out-of-the-box, such as SAP, SharePoint, WebLogic. These applications accept assertions. 
• A direct connection to a centralized server is unnecessary. A federation request always goes through the asserting party to get the generated assertion. After a user gains access to content on one server, the user returns to the federation hub and gets redirected to the next server. Only if the user session times out at the hub does the user have to reauthenticate. 

These advantages make federated partnerships better for an environment where sites are remote, inaccessible, or under third-party control.

Single Sign-On (WAM) has the following advantages:

• Transactions are faster because there are fewer browser redirects. 
• Provides centralized authorization and auditing. 
• Direct links can exist from one web server to another in a network without the user going through a centralized hub for assertion generation. 
• Offers timeout management. 
• Applications are independent of a remotely initiated transaction. 

These advantages make WAM single sign-on better suited to an environment with sites that are under your control, such as internal data centers.

.

Quick look at SSO through the ages

I found this article few days back... An interesting map of the road I have travelled so far... :)

Let’s take a quick look at SSO through the ages.

• It started with password synchronization, but that soon became too cumbersome, too labor-intensive, and required too much integration to be a true ”enterprise” solution. 
• Next we had the concept of enterprise SSO where all credentials were stored and the appropriate fields were automatically filled in when login was required. But ESSO doesn’t leverage more modern SSO concepts and is still difficult to implement and manage. 
• Finally we arrived at “true” SSO for Windows with the advent of Active Directory (AD), where a single account and a single credential provides universal access without any synchronization or form-filling. The problem is it only works for Microsoft stuff or things that you can get to play nice with AD, leaving many critical systems out in the cold. 
• Today we have the concept of federation, which is “true” SSO for web applications, but only if those applications talk the right standards, leaving lots of legacy web applications and all thick client apps out of the equation.

Never ending story if there is no common standard. By the way, there won't be any common standard in an ideal world. Contradicting? Yes, my take. 

.

Adaptive Risk Authentication

Adaptive Risk Authentication has been built into most SSO products these days. Should I say all? It used to be an add-on module or by-product, which customers have to pay extra. However, these days, we are seeing that this feature is shipped by default.


So, what makes a good authentication of choice? I found this slide from a CA webinar.

.

Device Identification to prevent Session Hijacking

This slide was from a webinar from CA I attended. It talked about how to prevent session hijacking by using device identification techniques.

So, besides ensuring the user is coming in from a "trusted" device during initial authentication, each access to a protected application is validated again. 

This can be quite resource intensive, but if an application is sensitive and of highest importance to customers, then it makes sense.

.

Mobile . Social Login . Single Sign-On

I was attending a webinar by CA - Enabling and Securing Multi-Channel Customer Interactions. 

Some points caught my attention:

• replace traditional channels with mobile apps if the same customer service features were available
• consumers prefer to use a company's mobile app for routine inquiries rather than calling the company on the phone
• consumers have a more positive view of a company if they have a customer service app

 Social Login benefits:

• access to large volume of social media users
• higher level of conversion to internal prospect list
• more targeted marketing opportunities

Now, based on the facts above, more and more decision makers will move businesses towards the Mobile and will offer Social Login.

Single Sign-On solutions in the market has to get:

• easier to deploy (Cloud ?)
• easier to integrate with Social Login providers
• more secured
• to scale even better and quicker

It's an exciting time to be in now!

.

Where to store Password Policy?

Any Single Sign-On product in the market will need to talk to a back-end User Store for authentication purpose. A User Store can be a traditional LDAP server or a modern Microsoft Active Directory Server.

Now, the SSO product fronts the end-users and this is where Password Policy is enforced. (Of course, if a corporate environment is using Microsoft platform, then password policy can be enforced during the Windows logon process)

Today, I talked to a Product Pre-Sales engineer and was pretty pissed off. She knew my team is managing the SSO product, as well as the LDAP server for a customer. We have a migration exercise going on at the moment.

My customer wants us to make use of the out-of-the-box features from the SSO product as much as possible - to the extend of making sure the Password Policy implemented on the LDAP server can be seamlessly integrated with this SSO product.

We spent a few days reading up and setting up a POC in our labs. We confirmed that this SSO product is not able to "interact" with any underlying LDAP server with regard to Password Policy management. It is only able to implement its own password policy.

She insisted that the RIGHT WAY of doing thing is for the SSO product to enforce password policy for the corporate.

This is "vendor-lock-in" strategy. You think customer is stupid?

I have implemented many SSO projects. In Sun's days, when the old Sun Access Manager and OpenSSO server could not integrate seamlessly with Microsoft Active Directory, we did not tell our customers that was the wrong way of enforcing password policy and they should use Sun AM/OpenSSO built-in password policy instead.

We stripped the codes and implemented custom authentication module for our customers.

User Store (LDAP server or Microsoft Active Directory Server) should be the authoritative password policy enforcer.

Wake up, lady!

.

Native Mobile Application SSO

This article (Native apps and the NAPPing giant for mobile SSO) from Ping Identity is good read. It talks about the limitation of OpenID Connect for mobile native applications.

... native application model should be with us for a while...

Federation protocols such as SAML, WS-Federation, and OpenID - designed to enable SSO for browser applications, don't work so well for native mobile applications. Consequently, OAuth, and more recently OpenID Connect, have emerged. 

While optimized for the authorization and authentication of native applications, OAuth 2.0 and OpenID Connect do not themselves enable SSO across native applications, i.e. the authentication performed for one application is not generally shared for a different native application.

In OpenID Foundation, a new group - Native Applications (NAPPS) Working Group will define a profile of OpenID Connect (OIDC) that will enable a standardised cross-app SSO experience - for both consumer-centric and enterprise applications.

Pretty cool!

.