The Pharma customer has to achieve a solution for the administrators to secure access to corporate applications by a Multi-factor authentication and without typing a password.
Here the principal requiremets:
- The administrators must login to the different target systems without password (they don’t know it). Only the Security Manager knows these passwords that can be different for all the target systems (applications or server).
- central repository to manage these passwords with a web interface. Only the Security Manager can access to this interface
- every administrator has to have a profile (Domain/User) defined on a Windows Domain and an LDAP (Active Directory).
- a token RSA (SecurID SID700) will be provided to the administrators that must use the OTP (and a fixed PIN) to login to Windows.
- List of all the target systems:
- Server AIX (about 170)
- Oracle Database (managed via Client SQL*Plus)
- Login Netware for the Novell network
- Login Windows with Remote Desktop
In this section will be showed the functional architecture of the eSSO project and different Use Cases.
- Client Login to an application with eSSO with the RSA protection
- Client Login to an application with eSSO without the RSA protection
- Client Login to an application without eSSO
Hardware Components for the Solution
- RSA Appliance 130 (with RSA Authentication Manager 7.1)
- RSA token SecurID SID 700
Software Components for the Solution
- Oracle ESSO-LM 220.127.116.11 Logon Manager (on the clients with OS Windows)
- Oracle ESSO-PG 18.104.22.168 Provisioning Gateway Client (on the clients with OS Windows)
- Oracle ESSO-PG 22.214.171.124 Provisioning Gateway (on a dedicated Windows 2008 Server)
- RSA Agent 6.1.3 (on the clients with OS Windows XP), RSA Agent 7.0.2 (on Windows 7)
Client Login to Windows
As you can see above, the user that login to the laptop use a two steps authentication:
- Put the One Time Password (OTP), listed the RSA SecurID Token, on the Windows page. The OTP will be checked versus the Appliance RSA
- If the authentication was successful, the user put the Domain credentials that will be checked vs the Domain Controller (phase 1).
After both authentications, user starts the logon process (phase 2). In this phase (3) the eSSO-LM component synchronize the template information to the user (Logon Manager) and the eSSO-PG queries the eSSO Provisioning Gateway to check the credentials (any update).
From this moment the user is able to connect to the target system. Let’s see the three different use cases.
- Client Login to an application with eSSO with the RSA protection.
In this Use Case, eSSO-LM check if he’s already the credentials locally and then a login window will be prompt. The login window must be filled with username, OTP (from token RSA) that will be checked vs RSA Appliance (phase 4). If the code is correct, RSA Appliance authorizes eSSO-LM to insert the credentials (phase 5).
- Client Login to an application with eSSO without the RSA protection.
This use case is very similar to the 1. The only difference is that at the user will not be prompt the RSA authentication, but the eSSO-LM will insert the credentials (phase 6).
- Client Login to an application without eSSO.
If the application doesn’t have a template associated, eSSO-LM will ignore the request and will not provide support for the authentication phase (phase 7).
At runtime, or after the logoff, the credentials will be synchronized to the AD (phase 8).