richard.chetwynd | February 9th, 2021
For those of you who participate in our Early Preview program for Smart Hooks, we recently released some changes we think you will love.
It’s been awesome to learn more about the authentication challenges and unique compliance use cases that many of our customers experience, and then design Smart Hook implementations to solve them.
It became clear early on that we need more contextual information in the pre-authentication hook to solve many of the use cases. We created the following additions to capture the contextual information.
- MFA device information
- Last successful login date
- Service Provider initiated login app information
- Semantic versioning for hook contexts
{
"user": {
"user_identifier": "jim-hendrix",
"policy_id": 187345,
"id": 36216766,
"last_login_success": "2020-10-21T17:04:22.852Z",
},
"device": {
"user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.121 Safari/537.36",
"is_mobile": false
},
"location": {
"ip": "120.118.218.225",
"country_code": "TW"
},
"risk": {
"score": 30,
"reasons": [
"Infrequent access from 120.118.218.225",
"Infrequent access from Kaohsiung City, Kaohsiung, Taiwan",
"Infrequent access from Taiwan",
"Infrequent access using Chrome on Windows",
"Low trust for session"
]
},
"mfa_devices": [
{
"auth_factor_id" 16885,
"device_id" 1825100,
"user_display_name" "Google Authenticator",
"type_display_name" "Google Authenticator",
"auth_factor_name": "Google Authenticator",
"default": true,
"last_used_at": "2020-10-20T12:33:24.266Z",
"created_at": "2020-03-02T14:53:00.445Z"
}
],
"app": {,
"id: 959314,
"uuid": "1a650385-d500-42e3-921e-14aa4020ae70",
"name": "OIDC - PKCE",
},
"correlation_id": "13a97251-215d-4fa5-baaf-6fc15700a2db",
"request_id": "7d436b7e-b4a3-4b48-83fd-f4a12c22bb62"
}
MFA Device Information
You can now get back a list of MFA devices that are registered for a user. To enable this, you must send the mfa_device_info_enabled property set to true in your hook config.
{
"type": "pre-authentication",
"function": "",
"disabled": false,
"runtime": "nodejs18.x",
"retries": 0,
"timeout": 1,
"risk_enabled": false,
"location_enabled": true,
"mfa_device_info_enabled": true,
"env_vars": [
],
"packages": {
}
}
When enabled, the users’ MFA devices will be included in the context, as pictured below.
{
other context items....,
"mfa_devices": [
{
"auth_factor_id" 16885,
"device_id" 1825100,
"user_display_name" "Google Authenticator",
"type_display_name" "Google Authenticator",
"auth_factor_name": "Google Authenticator",
"default": true,
"last_used_at": "2020-10-20T12:33:24.266Z",
"created_at": "2020-03-02T14:53:00.445Z"
}
],
}
This is useful if you want to force a policy based on the devices a user has registered. For example, if a user is on a mobile device with the WebAuthn biometric factor registered, then you may want to dynamically assign them to a policy that enforces the use of that factor.
Alternatively, you may want to use the last_used_at
attribute to force a user to MFA every X number of days. This is useful if you have Smart MFA enabled to suppress MFA due to a low risk score because your users always log in from home. You may want to keep them on their toes with a regular MFA prompt, regardless of the detected risk level.
Last successful login date
Sometimes it’s useful to know the last time a user successfully logged in. For this, we added last_login_success to the context which allows you to make decisions based on the last time the user successfully logged in. For example you may want to force a user to update their password if they haven’t logged in for over 30 days.
{
"user": {
"user_identifier": "jim-hendrix",
"policy_id": 187345,
"id": 36216766,
"last_login_success": "2020-10-21T17:04:22.852Z",
},
…
}
Service Provider initiated login app information
For Service Provider (SP) initiated logins, you now see App information in the context which indicates the specific app used to initiate the login flow.
{
other context items....,
"app": {,
"id: 959314,
"uuid": "1a650385-d500-42e3-921e-14aa4020ae70",
"name": "OIDC - PKCE",
}
There are many out of the box App Policy settings available to control access to applications. If you include this information in the pre-authentication hook context, it now provides the flexibility to control which user policy should be applied, based on the application that is being accessed.
Check out Postman
Smart Hooks is an exciting new extensibility option for OneLogin customers to customize workflows and solve edge cases that aren’t supported out of the box.
We are building a library of sample code snippets to resolve the challenges you experience while using the methods that work best for you.
All of the sample code snippets are added to our Smart Hooks collection in Postman, which offers a Low Code solution for customization and deployment.
Download our collection today and let us know how you get on.