Overview
The AssessTech suite of applications all have their own method of authentication and authorisation, and in the case of ACMS there is a management system to control access by mobile applications (in essence, a complete subsystem). As a result, there is no ‘one size fits all’ method of integrating an external SSO system, as there are so many different, and competing requirements.
To solve this problem AssessTech will use an internal central LDAP (ApacheDS) repository which will contain user and policy information (shown as ‘AssessTech LDAP’ on the diagram). All access to AssessTech systems will be facilitated using a binding against the AssessTech LDAP server.
Entries in the AssessTech LDAP server will define how users access each system, and their permissions.
One of the features of ACMS in particular is the fine-grained permission system, which has been built upon to create profiles for different types of user. This is also used to specify access to the mobile applications.
Use Cases
There are a number of different use cases for authentication and authorisation:
- No SSO in use
- Customer asks AssessTech to provide SSO just for the AssessTech Systems
- Customer asks AssessTech to integrate with their SSO implementation.
Options 1 and 2 essentially amount to the same thing and are described below under ‘Default Case’. Option 3 is described under ‘Customer SSO Integration Case’.
Default Case
Accounts will have some additional attributes which will define how the user is authenticated. The default case is that the password is stored (and hashed) against the user record held in the AssessTech LDAP server and will require a bind against that entry to authenticate the user.
This is how ACMS, AssessBook, AssessTube and all mobile Apps work today.
Offline login is supported on the mobile Apps because they hold a hashed version of the user’s password (just for the user lasted logged in).
Customer SSO Integration Case
The user record held in the AssessTech LDAP will contain the Fully Qualified DN on the Customer LDAP server with which we must successfully bind in order to authenticate the user.
In this case a time to live (TTL) must be applied to the user's last successful authentication, such that subsequent failed login attempts will cause the customers LDAP server to require intervention for the user to gain access. The length of the TTL is configurable by the customer.
It should be noted that no password will be passed over the wire, or stored in a plain text format anywhere on AssessTech Systems.
LDAP Bind Options
We would suggest that customer LDAP access be as light as possible and that the access to specific system be under the auspices of the AssessTech LDAP server. This is known as a ‘simple bind’.
However, if the customer wishes to control this remotely, they will need to import our schema files (DITs) into their LDAP servers, and be prepared to take updates to these as required (during the development of our products this may require a new DIT per release). We will call this option ‘extended bind’.
It should be noted at this time that a simple bind against a user base DN is the preferred approach at this time, to avoid the additional overhead of schema migrations.
Scenarios for User Login
To further illustrate the operation of this architecture we will consider users who are performing a login on the various AssessTech Platforms and Apps.
User ACMS Login
As ACMS is a Web Service accessed via a browser, then the user is online by definition. This makes this scenario really straightforward.
The user logs in with their credentials and these are checked against the AssessTech LDAP server. The check is handed off to the Customer LDAP server.
User AssessBook or AssessTube Login
This is exactly the same as a login to ACMS.
User ACMS Mobile App Login
The purpose of these mobile Apps is to provide the functions users typically need when they do not necessarily have an internet connection. So, there are two cases we must think about, online and offline.
Please note there is no difference between iOS and Android Apps in this respect.
User is Online
This is really straightforward. The user logs in to the App using their credentials and the App passes the check to ACMS (which passes it off to the AssessTech LDAP server as per an ACMS login).
In this case the App does not need to store any user credentials at all. This works well, but limits the user to only being able to login to the App when online and brings about a number of implications for App session times, etc. It would be no good for an Assessor to get halfway through an assessment, be logged out and then not be able to get back in because they had no internet connection.
User is Offline
In order to support offline login the Apps need to store a hash of the user credentials. It’s obviously not a good idea for every App to contain every user’s credentials, however a simple constraint can bring this under control.
The App can be limited to store only a hashed version of the last user’s login credentials. This means that a user must login to the App for the first time when they are online. If they subsequently get logged out the same user will be able to log back in when offline.
There are some considerations here about TTL values and App session times, but they are probably best discussed on a case by case basis and according to the type of App and Customer preferences.
Customer Infrastructure Requirements
The customer will need to provide access to an appropriately configured LDAP server, configured to use a secure transport and grants to perform binds against a known base DN:
Simple Bind
Using the Base DN of cn=users,dc=example,dc=com and an (objectclass=user) we can perform a bind against this unique entry to ascertain that the user is valid.
Extended Bind
If additional information about the user is stored in the customer LDAP repository, we can add additional object classes to the bind, and query the response to setup a user’s security context.
Technical Information
All providers of SSO solutions have good documentation on how to set up an LDAP server to support a remote bind.
As an example for Azure users, see the Microsoft documentation: https://techcommunity.microsoft.com/t5/sql-server/step-by-step-guide-to-setup-ldaps-on-windows-server/ba-p/385362
Other providers publish a similar level of detail.