Authentication Portal Authentication Options
The idenprotect Authentication Portal can be configured to support a range of different authentication options. This article explains what those different authentication options are.
To configure these authentication options, you can follow the guidance in Idenprotect Authentication Portal Configuration which shows you which settings are required to be set. This is generally done on the idenprotect Core Platform under Authentication Portal Configuration.
Before discussing the authentication options, it is worth noting that in addition to allowing or disallowing types of authentication, Service Providers and User Groups can also have their access restricted to certain types of authentication and Service Providers can additionally be restricted to certain groups. Configuring these restrictions are discussed in more detail in Authentication Portal Service Provider Configuration and LDAP Group Definitions
This can get complex as it allows multiple layers of restrictions, we have therefore provided a couple of examples to show how this can work.
For the purposes of these examples, the following example configuration is used
- Authentication Portal can be authenticated to using the idenprotect For Mobile applications, by using a One Time Code or by using an Active Directory Password
- Service Provider "1" can be authenticated to using a One Time Code
- Service Provider "2" can be authenticated to using an idenprotect For Mobile application or a One Time Code but is also restricted to Group "G"
- Group "G" permits authentication with the idenprotect For Mobile application and Active Directory Password
- User "A" belongs to Group "G"
- User "B" does not belong to any Group
User "A" example
User "A" goes to the Authentication Portal and enters their email address, by default, they are shown idenprotect For Mobile as an authentication option. In additional options, their group access restricts them to only seeing Active Directory as an additional option.
- If User "A" authenticates with the mobile device, they will be shown Service Provider "2" only when logged in. They are unable to use One Time Code as an authentication type and because they have not authenticated this way, they are not shown Service Provider "1".
- If User "A" authenticates with an Active Directory Password, they will be shown no Service Providers when logged in. Neither of the configured Service Providers allows Active Directory as an authentication option
User "B" example
User "B" goes to the Authentication Portal and enters their email address, by default they are shown idenprotect For Mobile as an authentication option. In additional options, as they do not belong to a group they do not have any group restricted authentication options so are shown all allowable. In this case, additional options will be One Time Code or Active Directory Password.
- If User "B" authenticates with the mobile device, they will be shown no Service Providers when logged in. Service Provider "2" allows using idenprotect For Mobile as an authentication option but access is restricted to members of Group "G". User "B" has not used the correct authentication type to access Service Provider "1".
- If User "B" authenticates with a One Time Code, they will only be shown Service Provider "1". They have now used the correct authentication type for Service Provider "1" but Service Provider "2" still restricts access to members of Group "G"
- If User "B" authenticates with an Active Directory Password, they will be shown no Service Providers when logged in. Neither of the configured Service Providers allows Active Directory as an authentication option.
idenprotect refers to authenticating by using the idenprotect For Mobile applications. By default, this is the only authentication option supported, after the user has entered their username they are shown instructions to open their idenprotect For Mobile application.
Any additional authentication options are available by selecting the Alternative Login Options button.
The idenprotect platform can send the user a notification to their device which when they click on it will open their idenprotect for Mobile application and start the authentication process. The user can request such a notification to be sent to them by selecting this option. It is also possible to configure a push notification to be sent automatically to the user after they have entered their username.
One Time Passcode Token
The idenprotect For Mobile application can be used as a One Time Passcode token or a user can be allocated a compatible OATH One Time Passcode Token. If the user selects this option they will be prompted to enter their one time passcode in order to authenticate.
One Time Passcode Message
As an alternative to using a physical token, the idenprotect Core Platform can be configured to send a one time code to the user, eg. via an SMS message. If the option is allowed when the user clicks on the send one time code option the user will be sent a one time code that they can then enter to authenticate.
Active Directory Password
This option allows the user to authenticate to the Authentication Portal using their Active Directory password. Depending on the configuration, this may only allow the user access to a limited number of applications. By default, the idenprotect User Portal integration does not allow the user to authenticate with an Active Directory password.
As an alternative to receiving a push notification, the user can use their idenprotect For Mobile application to scan a QR code to initiate the authentication process.
Working with Passwords
The Authentication Portal can store passwords that the user has entered and use these passwords to authenticate the user to legacy applications that still require these passwords. The passwords are stored (cached) for a specific period of time or until the user logs out dependant on the configuration.
If password caching is required, even if the user is not required to use a password to authenticate, the Authentication Portal can be configured to prompt the user for a password as part of the authentication process.
Additionally, if you only want legacy applications to use the same credential as the user is using for their Active Directory account, the entered password can be verified against Active Directory. An unsuccessful verification will result in the password not being cached. If the user does not enter a password or if the password they enter is not valid for the service they wish to access, the user will have to manually enter their password when they are directed to that service from the Auth Portal home page.