2FA mobile app with Push Notification

Wow! I realized I have not blogged for the longest time, ever since pre-COVID. Have been super busy throughout the pandemic period with a lot of projects. 

We are still deploying and maintaining Gluu Server for our customers. In fact, customers are looking at getting more values from what Gluu can provide.

Recently, a customer asked for integrating Push Notification into their mobile application. This will provide a 2FA to their end users who are accessing their websites. 

I recalled we have an internal app that is "white-labelled" from SuperGluu. 

I wrote an article in GitHub - AZPass. We can copy some ideas from there and integrate into the mobile app for this customer.

 

Pretty cool stuff!

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.


.

Gluu Unexpected Error - login.errorSessionInvalidMessage

I was testing Cache Refresh in Gluu Server 3.1.6 with Microsoft Active Directory being my backend source server. 

After configuration, I hit into the following error when I wanted to simulate an end-user login.

So I went to /opt/gluu/jetty/oxauth/logs/oxauth.log and saw the following debug log:

(AuthorizeAction.java:253) - Failed to get CustomScriptConfiguration. auth_step: 1, acr_values: auth_ad_server

I'm stuck! No way to log in either as Gluu Administrator or end-user.

My last resort was to tweak the configuration database directly. In this case, OpenDJ directory server is the configuration database that Gluu Server is using.


The entry to search for looks similar to dn: inum=@!1E3B.F133.14FA.5062!0002!4B66.CF9C,ou=appliances,o=gluu

Quite obvious the configuration is screwed. I have no idea how auth_ad_server got set as the values for oxAuthenticationMode and oxTrustAuthenticationMode when it's enabled value is false!

Manually set them back to auth_ldap_server. Restart oxAuth server. Done!

The login page is back.

.