So, Good Old IBM Comes up with a new strategy for Mobile based Authentication system for ISAM.
For all the people who been using Google Authenticator can switch to IBM Verify App, It is intended to make it easier and more IBMer view...
I tried my hand on the new IBM Verify app with the intention of completely turning it inside out and trying out everything possible with it and my favourite ISAM for web..
It took sometime for me to understand and get used to the new Verify App, Although there are a few issues like all mobile based apps, it still feels good to use it...
Lets get to the Configurations of it....
Basically, this method can only be used if u have ISAM version of 9.0.2.1 or above....preferably 9.0.3...
If u are using base version of 9.0.2.1 then it will be pretty straight forward but if are using an upgraded version then u will have to replace your old html file templates to the new ones...
This basic setup needs generally two webseal environments...
the primary one where u will configure all the target applications and the other one for mobile....
These two webseals will work in sync to get ur communication to the Mobile App established...
IBM has given a very good explanation on their site about how it works so i will not be going into detail on it...
So lets start with it...
Firstly, load the certificate for the appliance in your pdsrv key store.
Browse to Manage System Settings> SSL Certificates..
select the pdsrv key store and click on manage and select the Edit SSL Certificate Database.
Select Signer Certificates and click on manage option and select load..
In the server field enter localhost, port give 443, and label give runtime...
this step will load the default localhost certificate to the pdsrv key store.
Now Browse to the reverse proxy page and edit the configuration files of both the default and mobile webseals to keep the below value in the file..
force-tag-value-prefix = no
Deploy and restart both the webseals..
Browse to the Secure Access Control > Global Settings > User Registry
Select the easuser and set a password for the user - In my case i am setting the password as "Passw0rd"
Deploy the changes..
Now Open the Default Webseal configuration file and make the below changes in it:
In the Server stanza make the below changes:
[server]
…
http-method-disabled-local = TRACE,PUT,DELETE,CONNECT
http-method-disabled-remote = TRACE,CONNECT
In the Server stanza make the below changes:
[session]
…
user-session-ids = yes
Add the following stanza to the end of the configuration file to manage cookies created by AAC Runtime so they are not returned to the browser
[junction:/mga]
reset-cookies-list = *ac.uuid,*JSESSIONID*
managed-cookies-list = *ac.uuid,*JSESSIONID*
Enable EAI authentication. Specify that when EAI is used for a re-authentication, the original session should be maintained. Specify that EAI should be able to override where the user is directed after authentication completes
[eai]
eai-auth = https
…
retain-eai-session = yes
eai-redir-url-priority = yes
Add the following trigger URLS for EAI:
[eai-trigger-urls]
trigger = /mga/sps/oauth/oauth20/session*
trigger = /mga/sps/auth*
trigger = /mga/sps/authservice/authentication*
trigger = /mga/sps/authsvc*
trigger = /mga/sps/apiauthsvc*
Add the following entries to the azn-decision-info stanza. This tells the Reverse Proxy what information from incoming requests to make available to the authorization engine
[azn-decision-info]
Accept = header:Accept
Accept-Charset = header:Accept-Charset
Accept-Encoding = header:Accept-Encoding
Accept-Language = header:Accept-Language
Authorization = header:Authorization
Cache-Control = header:Cache-Control
Connection = header:Connection
Content-Type = header:Content-Type
Host = header:Host
HTTP_HOST_HDR = header:host
HTTP_REQUEST_SCHEME = scheme
HTTP_REQUEST_METHOD = method
HTTP_REQUEST_URI = uri
HTTP_AZN_HDR = header:authorization
HTTP_CONTENT_TYPE_HDR = header:content-type
HTTP_TRANSFER_ENCODING_HDR = header:transfer-encoding
Missing = header:Missing
Pragma = header:Pragma
Transfer-Encoding = header:Transfer-Encoding
User-Agent = header:User-Agent
X-Requested-With = header:X-Requested-With
method = method
rspcode = header:rspcode
scheme = scheme
uri = uri
Add the following to the obligations-urls-mapping stanza. This maps incoming obligations to the browser endpoint of the Advanced Access Control authentication service.
This is actually different from how the the MMFA config tool sets things up, but for our browser-channel Reverse Proxy we do actually want the HTML-based authsvc URL rather than the apiauthsvc
[obligations-urls-mapping]
urn:ibm:security:authentication:asf:* = /mga/sps/authsvc
Configure Web Socket support. This is needed so that clients can connect to the Web Socket service that MMFA uses for notification of transaction completion.
[websocket]
max-worker-threads = 20
jct-read-inactive-timeout = 300
clt-read-inactive-timeout = 300
jct-write-blocked-timeout = 300
clt-write-blocked-timeout = 300
Save the Configuration file and deploy the changes and restart the webseal.
Now access the mobile webseal configuration file and make the below changes in it....
Remove PUT and DELETE from http-method-disabled-remote to allow these methods for non-local junctions
[server]
…
http-method-disabled-local = TRACE,PUT,DELETE,CONNECT
http-method-disabled-remote = TRACE,CONNECT
Enable creation of user session IDs for each session
[session]
…
user-session-ids = yes
Add the following stanza to the end of the configuration file to manage cookies created by AAC Runtime so they are not returned to the browser:
[junction:/mga]
reset-cookies-list = *ac.uuid,*JSESSIONID*
managed-cookies-list = *ac.uuid,*JSESSIONID*
Disable form-based login. Mobile devices will only authenticate with OAuth.
[forms]
forms-auth = none
Configure the Reverse Proxy to internally follow redirects related to calling the Authentication Service (in response to Obligations). This is needed because typically REST clients don't handle redirects well.
[server]
# These will allow WebSEAL to internally follow redirects for authentication
follow-redirects-for = GET /mga/sps/apiauthsvc*
follow-redirects-for = PUT /mga/sps/apiauthsvc*
Enable OAuth authentication:
[oauth]
oauth-auth = https
default-fed-id = https://localhost/sps/oauth/oauth20
Provide the basic-auth-user for authentication to the OAuth token validation endpoint. Add the other lines specified to set up the connection:
[tfim-cluster:oauth-cluster]
basic-auth-user = easuser
server = 9,https://localhost/TrustServerWS/SecurityTokenServiceWST13
basic-auth-passwd = Passw0rd
ssl-keyfile = pdsrv.kdb
ssl-keyfile-stash = pdsrv.sth
Allow headers to be used for end-user sessions (rather than only for multiplexing proxy sessions):
[session]
require-mpa = no
Enable sessions using the Authorization header as the session index (rather that a session cookie):
[session-http-headers]
Authorization = https
Click Save to save the updated configuration.
Deploy the changes and restart both the default and mobile Reverse Proxy instance.
Now create a standard junction /mga for both default and mobile webseals with the below values...
Junction - /mga
SSL - yes
Target Backend Server hostname - localhost
port - 443
HTTP Basic Authentication Header - Ignore
headers to be passed - iv-user, iv-groups, iv-creds
set HTTP Header Encoding as UTF-8 URI Encoded
Enable the junction cookie
set Junction Cookie Javascript Block as Inhead
also select the check boxes for Include session cookies and Insert Client IP Addresses
make sure to create the junction in both default and mobile webseals
There are a few set of ACL's that need to be created..
To make it much easier i have given the commands that we need to run for creation of ACL and attaching them to the corresponding Object Spaces.
acl create isam_mobile_anyauth
acl modify isam_mobile_anyauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_anyauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_anyauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_anyauth set any-other Tr
acl modify isam_mobile_anyauth set unauthenticated T
acl attach /WebSEAL/myisam-default/mga/sps/auth isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/xauth isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/clients isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/common/qr isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/html isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/html isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/ac isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/wssoi isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/app/mobile-demo isam_mobile_anyauth
acl attach /WebSEAL/myisam-mobile/mga/sps/oauth/oauth20/logout isam_mobile_anyauth
acl create isam_mobile_unauth
acl modify isam_mobile_unauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_unauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_unauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_unauth set any-other Tr
acl modify isam_mobile_unauth set unauthenticated Tr
acl attach /WebSEAL/myisam-default/mga/sps/authsvc isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/authservice/authentication isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/authorize isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/session isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/token isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/static isam_mobile_unauth
acl attach /WebSEAL/myisam-default/app/mobile-demo/theme isam_mobile_unauth
acl attach /WebSEAL/myisam-default/app/mobile-demo/oauth/oauth2Client.jsp isam_mobile_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/details isam_mobile_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/oauth/oauth20/token isam_mobile_unauth
acl create isam_mobile_nobody
acl modify isam_mobile_nobody set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_nobody set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_nobody set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_nobody set any-other T
acl modify isam_mobile_nobody set unauthenticated T
acl attach /WebSEAL/myisam-default/mga isam_mobile_nobody
acl attach /WebSEAL/myisam-mobile/mga isam_mobile_nobody
acl create isam_mobile_rest
acl modify isam_mobile_rest set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_rest set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_rest set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_rest set any-other Tmdr
acl modify isam_mobile_rest set unauthenticated T
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/otp isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/device isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/questions isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/grant isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/authenticators isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/auth_methods isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/qr_code isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/transactions isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/websock/mmfa-wss isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/otp isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/device isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/questions isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/grant isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/authenticators isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/auth_methods isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/qr_code isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/transactions isam_mobile_rest
acl create isam_mobile_rest_unauth
acl modify isam_mobile_rest_unauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_rest_unauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_rest_unauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_rest_unauth set any-other Tmdrxl
acl modify isam_mobile_rest_unauth set unauthenticated Tmdrxl
acl attach /WebSEAL/myisam-default/mga/sps/apiauthsvc isam_mobile_rest_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/apiauthsvc isam_mobile_rest_unauth
After all this we come to one of the most important concepts in this configuration (i.e) The SCIM Configuration(System for Cross Domain Identity Management):
The name might confuse but its one of the most interesting concepts in the new version of ISAM. This configuration can be used to connect to different types of targets like(LDAP,Oracle,DB2,Webservices etc)
In our case we will use this functionality to verify if the user entered is in the LDAP or not...
Browse to secure accees control > Global Settings > Server Connections.
Click on new and select LDAP option...
In the New connection modal window enter the name and description.
On the server tab make sure to give your ldap details of where the user details exists.
In this case i am not using ssl but in case if u are using ssl make sure to add the certificate in the keystores and point that keystore for certificate.
basic details for connecting to LDAP include hostname, port, userdn(i have used cn=root for full priveleges but its better to use an id which has atleast lookup privileges) and password..
In case if u are using the embedded ldap then its better to use "cn=root,secAuthority=Default" as the userdn...
Save the Changes and Deploy...
Now browse to Secure Access Control > Manage > SCIM Configuration....
Select the User Profile Tab..
In the Server Connection select the server connection u created in the above step and in the search suffix and user suffix its best to give the top most OU.
Click on save and if there is any error in the server details that u have provided in the server connections the connection failed error will be displayed..
If all the details are correct and isam is able to communicate to the LDAP then it will give a message to deploy the changes...
Now switch to ISAM User tab in the SCIM Configuration page...
Select the check box for both Enable ISAM Integration and Update Native Users and inthe ISAM User Registry select the Server connection that u have created above.
Save and deploy the changes...
Browse to the Reverse Proxy page and create a junction called /scim junction in the default and mobile webseals with the below details...
Create a transparent junction /scim for both default and mobile webseals with the below values...
Junction - /scim
create transparent path junction - yes
SSL - yes
Target Backend Server hostname - localhost
port - 443
In Basic Authetnication tab select the checkbox for enabling basic authentication and give the credentials for easuser in the username and password field.
HTTP Basic Authentication Header - Filter
headers to be passed - iv-user, iv-groups, iv-creds
set HTTP Header Encoding as none
set Junction Cookie Javascript Block as none
also select the check boxes for Include session cookies and Insert Client IP Addresses
save and it should show a message in blue colour saying junction created successfully.
Edit the Webseal configuration for both the webseals(default and mobile) to make the changes in the configuration file...
In the [filter-content-types] stanza add the following entry:
[filter-content-types]
type = application/scim+json
In the [script-filtering] stanza, enable script filtering and replacing absolute URLs with absolute URLs:
[script-filtering]
script-filter = yes
#rewrite-absolute-with-absolute = no
rewrite-absolute-with-absolute = yes
Deploy and restart the webseals...
Make sure u do these in both the webseals(default and mobile)
Enter the following command to attach an ACL allowing all REST methods to the SCIM endpoint associated with the mobile Reverse Proxy instance
acl attach /WebSEAL/myisam-mobile/scim isam_mobile_rest
Although not strictly required for MMFA, we will also enable all REST methods to the SCIM endpoint associate with the default Reverse Proxy instance. This allows SCIM modify functionality to be demonstrated via the built-in test application. Without this, only GET requests are possible.
acl attach /WebSEAL/myisam-default/scim isam_mobile_rest
Create SCIM admingroup and two users named scimadmin and testuser using the below commands...
group create adminGroup cn=adminGroup,dc=iswga adminGroup
user create scimadmin cn=scimadmin,dc=iswga scimadmin scimadmin Passw0rd
user modify scimadmin account-valid yes
group modify adminGroup add scimadmin
u c testuser cn=testuser,dc=iswga Test User Passw0rd
u m testuser a yes
the above values will change according the type of ldap u are using, in my case i am using the embedded LDAP so the suffix dc=iswga
Test the SCIM configuration using the inbuilt SCIM demo Application...
Browse to Manage System Settings > System Settings > Advanced Tuning Parameters...
Select the new button and Enter scim_demo_enabled as the Key and true as the Value. Click Save Configuration.
Deploy changes using the link in the yellow warning message.
Access the url https://myisam/scim/demo.html
Here myisam refers to the default webseal...
Login with testuser created above using the commands
Now in the general tab check the values being displayed if the values are of the user logged in or not...
click on isam tab and verify if the values being displayed are the values of the user logged in or not...
If these details are correct the SCIM Configuration is Successfull.
Now login back to the VA Admin console and browse to the secure access control > Policy > API Protection...
Click on Create button and create a new API Protection with the below values...
Name : Authenticator
under grant types only enable the check box Authorization Code...
Expand the Token Management section and check the check-box for Enforce single-use authorization grant.
Click Save at the top of the screen.
Deploy changes using the link in the yellow warning message.
Browse to the Clients tab on the API Protection page and create a new client with the below values.
By default the Client ID is a randomly generated string but that complexity is not required here.
Enter AuthenticatorClient as the Client ID.
Enter Authenticator Client as the Client name.
Clear the Confidential checkbox. An MMFA client is generally running on in an untrusted environment (i.e. a mobile device) and so a client secret has little value (and in any case we only want to allow a specific redirect).
Enter the following as the Redirect URI:
https://myisam/mga/sps/mmfa/user/mgmt/html/mmfa/qr_code.html?client_id=AuthenticatorClient
Here myisam refers to the default webseal...
This makes sure that after the OAuth Authorization Grant is generated control is returned to the MMFA registration function.
Enter a company name...in my case i have used IBM as the Company name
and click OK.
Deploy the changes using the link in the yellow warning message
Now Comes the most important part of this exercise the MMFA endpoint configuration.
Navigate to Secure Access Control > Manage > MMFA Configuration.
Click on Wizard to begin configuration.
Set the Client ID to AuthenticatorClient, and the Reverse Proxy URL to https://<ip or hostname of your mobile webseal>:<port on which your webseal is running on>
make sure to give the correct the ip and port, any issues in it will lead to improper configuration and your whole configuration will fail....
Click on Next and it will display the discovery endpoint, token endpoint, HOTP Shared secret Endpoint and TOTP Shared secret endpoint... all these values will be prefilled..
Click on Next and this time it will show the enrollment endpoint and the transaction endpoint..click on next
now it will show the endpoint prefix... all these will be prefilled except the first box...
now click on save and deploy the changes...
Navigate to the Discovery Mechanisms tab on the same page and click Add.
Select urn:ibm:security:authentication:asf:mechanism:mobile_user_approval:fingerprint from the drop-down list and click Save.
Repeat this step to add the following additional mechanisms:
• urn:ibm:security:authentication:asf:mechanism:mobile_user_approval:user_presence
• urn:ibm:security:authentication:asf:mechanism:totp
Navigate to the Custom QR Code Options menu, and click Add.
Enter ignoreSslCerts as the Key and true as the Value.
This option will be added to registration QR codes and instructs IBM Verify that it is OK to connect to SSL endpoints which do not host a valid SSL certificate. You would not set this in a production environment but we need it for our test system.
Click Save and deploy the changes...
Now it is time to test the full configuration....
Access the below url for registering the device...
https://myisam/mga/sps/mga/user/mgmt/html/device/device_selection.html
Here myisam refers to the default webseal...
This page shows all the new authenticators added to the user(i.e) all the devices registered for the user...
Click on Register new Authenticator button...
This will trigger a request to the below url....
https://myisam/mga/sps/oauth/oauth20/authorize?client_id=AuthenticatorClient&response_type=code&scope=mmfaAuthn
Here myisam refers to the default webseal...
if its doesnt redirect then there is an issue with the html file... In case of the upgraded system from an older version to the 9.0.3.0 version the html files will not be updated::::
So browse to Manage System Settings > secure Settings > File Downloads...
Now expand and go to acces control > pages > C > mga > user > mgmt
Download the files design.css, common.js, device_selection.html, device_selection.js and style.css
Now browse to the secure access control > global settings > template files..
expand the C > mga > user > mgmt and delete the files design.css, common.js, device_selection.html, device_selection.js and style.css...
Deploy the changes and now upload the new files that we downloaded from the file downloads option...
design.css, common.js, device_selection.html, device_selection.js and style.css, upload them and deploy the changes...
It generally doesnt sync the new js files that were uploaded.. its better to restart the machine and try the url for device registration again....
After u click on the register new authenticator the page will redirect to a new page which contains the QR CODE...
Now scan the QR Code from the IBM VErify APP in your mobile..(u can download the free ibm verify app from the app store for ios and google play store for andriod devices)
Make sure your mobile can communicate to the webseal (i.e) either your mobile and webseal are in the same network or your webseal is exposed to the internet..
and also for all the dummies out there the app needs internet so please do connect to internet before doing this activity...
A success message is shown saying the device is successfully registered....
in case of error please check ur configurations again...
After it is successfully registered..on your mobile Touch Got it! to continue. You can now set up notifications – this allows IBM Verify to alert you when a new MMFA transaction is pending. Touch Notify Me and then Allow to enable.
You are now offered the option to enable the fingerprint authentication method, provided your device supports it. Touch Use Touch ID to continue (on mobile device). Present you fingerprint when prompted to unlock secure storage.
The fingerprint authentication method will work only onthose devices which have inbuilt finger censor in them...
sadly dowloading fingerprinst secure apps will not work for this..😒
Once it is successfully configured your mobile will show a success message now go to the accounts on your mobile and u will find a new account that got registered with the ipaddress/hostanme of your mobile webseal and the userid shown below that..
clicking on that will show the access code or otp which keeps on changing every 30 or 60 seconds...this can also be used as a otp generator also...i still havent tested this OTP Feature but will test if i can use this otp as a RSA token generator but that is for an other day... 😃
Now go back to the device selection url on your browser ...
https://myisam/mga/sps/mga/user/mgmt/html/device/device_selection.html
Here myisam refers to the default webseal...
it will show the authenticators tab the newly configured device will be shown with an id staring with uuid**********....click on the uuid********* and it will show the details that were obtained from your mobile phone...like the OS VErsion, fingerprint support and other details...
This Completes the device Registration using IBM Verify...
Password Less Login Scenerio using the IBM Verify App:
This scenerio will work based on the userid that is sent in the url..
We will read the username from a username parameter sent in the url to the Authentication Service.
Navigate to Secure Access Control > Policy > Authentication.
On the policies tab click New button to create a new authentication policy.
Enter MMFA Initiate Login Policy as the Name. This is the human-readable name for the policy.
Enter mmfa_initiate_simple_login in the Identifier box. This will be appended to the text already shown which makes the full identifier: urn:ibm:security:authentication:asf:mmfa_initiate_simple_login.
Enter a Description.
Ensure the Enabled checkbox is checked.
An authentication policy consists of one or more steps.
Click Add Step button to add the first step.
Select MMFA Authenticator mechanism from the drop-down list. Then click the properties icon next to it to bring up the properties editor.
In this first example, we will set up the most simple initiate policy possible by using fixed values for most parameters. we can use dynamic values to make things more interesting also and all these can be acheived in Authentication page using a combination of javascripts and authentication mechanism...
.
Select the checkbox next to contextMessage and set the value to Please verify login to myisam. This is the text that will be displayed to the user in the Authenticator Client application.
Select the checkbox next to mode. The default value of Initiate is what we want so don't change it. This tells the mechanism that it is initiating the challenge to the Authenticator Client.
Select the checkbox next to policyURI. Set the value to: urn:ibm:security:authentication:asf:mmfa_response_userpresence
This is Policy ID of the authentication policy that will handle the challenge response from the Authenticator Client. We are going to create this authentication policy in the next step.
The only parameter that is dynamic here is the username parameter. This species the user for which the challenge should be generated. Obviously this needs to be the user that we want to log in. We will read this value from a query string parameter of the request sent to the authentication service. The query string parameter is also named username.
Select the checkbox next to username. Select Request from the drop-down list for Source. This indicates that we will read from the incoming Request.
Enter urn:ibm:security:asf:request:parameter as the Namespace for the value. This is a defined namespace that provides access to query-string parameters of the incoming HTTP request.
Enter username as the Attribute Id. This is the name of the query-string parameter to use.
Click OK to close the parameters window.
Click OK to add the workflow step. Then click Save at the top of the window to save the Policy.
A warning is shown to indicate there is an undeployed change. There is no need to deploy yet though because we have more configuration to do
We have created a authentication policy for sending a request now we need to create another Authentication Policy that will handle the 2nd half of the MMFA process. It performs the challenge/response with the Authenticator Client and then marks the MMFA action complete.
Click the new button to create another new Authentication Policy.
Enter MMFA User Presence Response as the Name.
Enter mmfa_response_userpresence in the box for Identifier.
This makes the complete ID for this authentication policy urn:ibm:security:authentication:asf:mmfa_response_userpresence which matches what we configured as the policyURI in the "initiate" policy.
Enter a Description.
Ensure the Enabled checkbox is checked.
Click Add Step to add the first mechanism to the policy.
The first step in this policy handles the MMFA user presence challenge/response. This uses a pre-defined authentication mechanism called User Presence Approval. Select this from the drop-down list. There are no special properties we need to set.
Click OK to confirm addition of the User Presence Approval mechanism to the policy.
Click Add Step again to add a second step to the policy.
Select MMFA Authenticator from the drop-down list. This is the same mechanism that we used in the "initiate" policy but this time we are going to use it in "response" mode.
Click the properties icon to open the parameters screen.
The only parameter we need to set is the mode. Select the checkbox for mode and set the Value to Response using the drop-down list. This tells the mechanism that it is responsible for completing the MMFA process that was started in the "initiate" policy.
Click OK to close the parameters window.
Click OK to confirm addition of the MMFA Authenicator mechanism to the policy.
Click Save at the top of the window to save the new Authentication Policy.
Deploy changes using the link in the yellow warning message.
Our first MMFA Process is now ready to use. It will be triggered manually by calling the ISAM Authentication Service and requesting the "initiate" policy using its Policy ID.
Setting the Authentication levels:
In this case we will set the mobile login or the password less login mechanism as the higher priority than the password based mechanism...
By default, unauthenticated sessions are level 0, password authentication is assigned level 1 and EAI authentication (which is what the AAC Authentication Service uses) is assigned level 2. In this environment, we want to make MMFA authentication level 1 and password level 2. This requires a change in the Reverse Proxy configuration file.
Navigate to Secure Web Settings → Manage: Reverse Proxy,
Select the radio button for the default Reverse Proxy instance. Click on Manage and select ConfigurationEdit Configuration File from the pop-up menu. This will open the configuration file.
To find a location in this file, use the browser's search function. On Firefox this is activated using Ctrl-f.
Locate the [authentication-levels] stanza and make changes as below.
[authentication-levels]
#----------------------
# STEP UP
#----------------------
# authentication levels
#
# Syntax:
# level = <method-name>
…
#
level = unauthenticated
level = ext-auth-interface
level = password
The order of these levels assigns the authentication levels. With this setting, unauthenticated is 0, ext-auth-interface is 1, and password is 2. This order is important, and is required to allow the ext-auth-interface to be used for step-up authentication in the later advanced password-less login scenario.
Click Save to save the updated configuration.
Deploy changes using the link in the yellow warning message.
Restart the default Reverse Proxy instance.
Access the pdadmin console and execute the below command
acl attach /WebSEAL/myisam-default/mga/websock/mmfa-wss isam_mobile_rest_unauth
object modify /WebSEAL/myisam-default/app set attribute HTTP-Tag-Value AUTHENTICATION_LEVEL=authentication_level
To Test password less login: access the below url
https://myisam/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:mmfa_initiate_simple_login&username=testuser&Target=https://myisam/
Notice that the URL specifies the PolicyId out our "initiate" policy and also provides the user ID of our test user (testuser) in the query string. It also includes a Target parameter which specifies where the user should be sent after successful login.
Select the device that was registered earlier and click Submit.
At this point the Initiate Policy creates an MMFA transaction and displays a "pending" page to the user:
This page is based on a template which can be modified. It includes client-side JavaScript which connects to the transaction status endpoint (via Web Socket) and waits for status updates.
On this page are a set of buttons which trigger actions for the MMFA transaction:
Verify: Polls the authentication service to determine the state of the MMFA process. This can be useful for environments where use of the Web Socket is not possible
Cancel: This cancels the MMFA process. The authentication service returns an error page.
Renotify: This resends the PUSH notification to the authenticator client (asuming PUSH notifications enabled)
Reselect Authenticator: This takes the user back to the device selection page so a different Authenticator client can be chosen to perform the MMFA verification.
now access the verify app in your mobile and click on the sync button (circular button at the top right hand corner) and this is enable a dot on your account...
Select your account now and it will ask for a message saying Please verify login to myisam... click the tick mark and the browser will automatically redirect to the target page...
Now in the above url the target is specified as https://myisam/ this will show be the favicon page...in the same way u can do modifications to you login age to identify here which url the user has requested and reroute that in the browser...
the username is given in the url as testuser...
To change this behaviour u can tweak the authentication policy to accept the username in a request from a html parameter or as a header also...
Now this is the basic method of configuring but this cannot be used in production...we can modify this to a much secure level with some changes to the authentication policy....
We can also add our own javascript to change the way we want this to work...
This method can even be used as a stepup configuration....but will do that all in another post...
For now...thank you and ciao....🙌💃👋
For all the people who been using Google Authenticator can switch to IBM Verify App, It is intended to make it easier and more IBMer view...
I tried my hand on the new IBM Verify app with the intention of completely turning it inside out and trying out everything possible with it and my favourite ISAM for web..
It took sometime for me to understand and get used to the new Verify App, Although there are a few issues like all mobile based apps, it still feels good to use it...
Lets get to the Configurations of it....
Basically, this method can only be used if u have ISAM version of 9.0.2.1 or above....preferably 9.0.3...
If u are using base version of 9.0.2.1 then it will be pretty straight forward but if are using an upgraded version then u will have to replace your old html file templates to the new ones...
This basic setup needs generally two webseal environments...
the primary one where u will configure all the target applications and the other one for mobile....
These two webseals will work in sync to get ur communication to the Mobile App established...
IBM has given a very good explanation on their site about how it works so i will not be going into detail on it...
So lets start with it...
Firstly, load the certificate for the appliance in your pdsrv key store.
Browse to Manage System Settings> SSL Certificates..
select the pdsrv key store and click on manage and select the Edit SSL Certificate Database.
Select Signer Certificates and click on manage option and select load..
In the server field enter localhost, port give 443, and label give runtime...
this step will load the default localhost certificate to the pdsrv key store.
Now Browse to the reverse proxy page and edit the configuration files of both the default and mobile webseals to keep the below value in the file..
force-tag-value-prefix = no
Deploy and restart both the webseals..
Browse to the Secure Access Control > Global Settings > User Registry
Select the easuser and set a password for the user - In my case i am setting the password as "Passw0rd"
Deploy the changes..
Now Open the Default Webseal configuration file and make the below changes in it:
In the Server stanza make the below changes:
[server]
…
http-method-disabled-local = TRACE,PUT,DELETE,CONNECT
http-method-disabled-remote = TRACE,CONNECT
In the Server stanza make the below changes:
[session]
…
user-session-ids = yes
Add the following stanza to the end of the configuration file to manage cookies created by AAC Runtime so they are not returned to the browser
[junction:/mga]
reset-cookies-list = *ac.uuid,*JSESSIONID*
managed-cookies-list = *ac.uuid,*JSESSIONID*
Enable EAI authentication. Specify that when EAI is used for a re-authentication, the original session should be maintained. Specify that EAI should be able to override where the user is directed after authentication completes
[eai]
eai-auth = https
…
retain-eai-session = yes
eai-redir-url-priority = yes
Add the following trigger URLS for EAI:
[eai-trigger-urls]
trigger = /mga/sps/oauth/oauth20/session*
trigger = /mga/sps/auth*
trigger = /mga/sps/authservice/authentication*
trigger = /mga/sps/authsvc*
trigger = /mga/sps/apiauthsvc*
Add the following entries to the azn-decision-info stanza. This tells the Reverse Proxy what information from incoming requests to make available to the authorization engine
[azn-decision-info]
Accept = header:Accept
Accept-Charset = header:Accept-Charset
Accept-Encoding = header:Accept-Encoding
Accept-Language = header:Accept-Language
Authorization = header:Authorization
Cache-Control = header:Cache-Control
Connection = header:Connection
Content-Type = header:Content-Type
Host = header:Host
HTTP_HOST_HDR = header:host
HTTP_REQUEST_SCHEME = scheme
HTTP_REQUEST_METHOD = method
HTTP_REQUEST_URI = uri
HTTP_AZN_HDR = header:authorization
HTTP_CONTENT_TYPE_HDR = header:content-type
HTTP_TRANSFER_ENCODING_HDR = header:transfer-encoding
Missing = header:Missing
Pragma = header:Pragma
Transfer-Encoding = header:Transfer-Encoding
User-Agent = header:User-Agent
X-Requested-With = header:X-Requested-With
method = method
rspcode = header:rspcode
scheme = scheme
uri = uri
Add the following to the obligations-urls-mapping stanza. This maps incoming obligations to the browser endpoint of the Advanced Access Control authentication service.
This is actually different from how the the MMFA config tool sets things up, but for our browser-channel Reverse Proxy we do actually want the HTML-based authsvc URL rather than the apiauthsvc
[obligations-urls-mapping]
urn:ibm:security:authentication:asf:* = /mga/sps/authsvc
Configure Web Socket support. This is needed so that clients can connect to the Web Socket service that MMFA uses for notification of transaction completion.
[websocket]
max-worker-threads = 20
jct-read-inactive-timeout = 300
clt-read-inactive-timeout = 300
jct-write-blocked-timeout = 300
clt-write-blocked-timeout = 300
Save the Configuration file and deploy the changes and restart the webseal.
Now access the mobile webseal configuration file and make the below changes in it....
Remove PUT and DELETE from http-method-disabled-remote to allow these methods for non-local junctions
[server]
…
http-method-disabled-local = TRACE,PUT,DELETE,CONNECT
http-method-disabled-remote = TRACE,CONNECT
Enable creation of user session IDs for each session
[session]
…
user-session-ids = yes
Add the following stanza to the end of the configuration file to manage cookies created by AAC Runtime so they are not returned to the browser:
[junction:/mga]
reset-cookies-list = *ac.uuid,*JSESSIONID*
managed-cookies-list = *ac.uuid,*JSESSIONID*
Disable form-based login. Mobile devices will only authenticate with OAuth.
[forms]
forms-auth = none
Configure the Reverse Proxy to internally follow redirects related to calling the Authentication Service (in response to Obligations). This is needed because typically REST clients don't handle redirects well.
[server]
# These will allow WebSEAL to internally follow redirects for authentication
follow-redirects-for = GET /mga/sps/apiauthsvc*
follow-redirects-for = PUT /mga/sps/apiauthsvc*
Enable OAuth authentication:
[oauth]
oauth-auth = https
default-fed-id = https://localhost/sps/oauth/oauth20
Provide the basic-auth-user for authentication to the OAuth token validation endpoint. Add the other lines specified to set up the connection:
[tfim-cluster:oauth-cluster]
basic-auth-user = easuser
server = 9,https://localhost/TrustServerWS/SecurityTokenServiceWST13
basic-auth-passwd = Passw0rd
ssl-keyfile = pdsrv.kdb
ssl-keyfile-stash = pdsrv.sth
Allow headers to be used for end-user sessions (rather than only for multiplexing proxy sessions):
[session]
require-mpa = no
Enable sessions using the Authorization header as the session index (rather that a session cookie):
[session-http-headers]
Authorization = https
Click Save to save the updated configuration.
Deploy the changes and restart both the default and mobile Reverse Proxy instance.
Now create a standard junction /mga for both default and mobile webseals with the below values...
Junction - /mga
SSL - yes
Target Backend Server hostname - localhost
port - 443
HTTP Basic Authentication Header - Ignore
headers to be passed - iv-user, iv-groups, iv-creds
set HTTP Header Encoding as UTF-8 URI Encoded
Enable the junction cookie
set Junction Cookie Javascript Block as Inhead
also select the check boxes for Include session cookies and Insert Client IP Addresses
make sure to create the junction in both default and mobile webseals
There are a few set of ACL's that need to be created..
To make it much easier i have given the commands that we need to run for creation of ACL and attaching them to the corresponding Object Spaces.
acl create isam_mobile_anyauth
acl modify isam_mobile_anyauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_anyauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_anyauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_anyauth set any-other Tr
acl modify isam_mobile_anyauth set unauthenticated T
acl attach /WebSEAL/myisam-default/mga/sps/auth isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/xauth isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/clients isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/common/qr isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/html isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/html isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/ac isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/mga/sps/wssoi isam_mobile_anyauth
acl attach /WebSEAL/myisam-default/app/mobile-demo isam_mobile_anyauth
acl attach /WebSEAL/myisam-mobile/mga/sps/oauth/oauth20/logout isam_mobile_anyauth
acl create isam_mobile_unauth
acl modify isam_mobile_unauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_unauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_unauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_unauth set any-other Tr
acl modify isam_mobile_unauth set unauthenticated Tr
acl attach /WebSEAL/myisam-default/mga/sps/authsvc isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/authservice/authentication isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/authorize isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/session isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/oauth/oauth20/token isam_mobile_unauth
acl attach /WebSEAL/myisam-default/mga/sps/static isam_mobile_unauth
acl attach /WebSEAL/myisam-default/app/mobile-demo/theme isam_mobile_unauth
acl attach /WebSEAL/myisam-default/app/mobile-demo/oauth/oauth2Client.jsp isam_mobile_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/details isam_mobile_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/oauth/oauth20/token isam_mobile_unauth
acl create isam_mobile_nobody
acl modify isam_mobile_nobody set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_nobody set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_nobody set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_nobody set any-other T
acl modify isam_mobile_nobody set unauthenticated T
acl attach /WebSEAL/myisam-default/mga isam_mobile_nobody
acl attach /WebSEAL/myisam-mobile/mga isam_mobile_nobody
acl create isam_mobile_rest
acl modify isam_mobile_rest set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_rest set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_rest set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_rest set any-other Tmdr
acl modify isam_mobile_rest set unauthenticated T
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/otp isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/device isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/questions isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mga/user/mgmt/grant isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/authenticators isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/auth_methods isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/qr_code isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/sps/mmfa/user/mgmt/transactions isam_mobile_rest
acl attach /WebSEAL/myisam-default/mga/websock/mmfa-wss isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/otp isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/device isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/questions isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mga/user/mgmt/grant isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/authenticators isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/auth_methods isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/qr_code isam_mobile_rest
acl attach /WebSEAL/myisam-mobile/mga/sps/mmfa/user/mgmt/transactions isam_mobile_rest
acl create isam_mobile_rest_unauth
acl modify isam_mobile_rest_unauth set group iv-admin TcmdbsvaBRrxl
acl modify isam_mobile_rest_unauth set group webseal-servers Tgmdbsrxl
acl modify isam_mobile_rest_unauth set user sec_master TcmdbsvaBRrxl
acl modify isam_mobile_rest_unauth set any-other Tmdrxl
acl modify isam_mobile_rest_unauth set unauthenticated Tmdrxl
acl attach /WebSEAL/myisam-default/mga/sps/apiauthsvc isam_mobile_rest_unauth
acl attach /WebSEAL/myisam-mobile/mga/sps/apiauthsvc isam_mobile_rest_unauth
After all this we come to one of the most important concepts in this configuration (i.e) The SCIM Configuration(System for Cross Domain Identity Management):
The name might confuse but its one of the most interesting concepts in the new version of ISAM. This configuration can be used to connect to different types of targets like(LDAP,Oracle,DB2,Webservices etc)
In our case we will use this functionality to verify if the user entered is in the LDAP or not...
Browse to secure accees control > Global Settings > Server Connections.
Click on new and select LDAP option...
In the New connection modal window enter the name and description.
On the server tab make sure to give your ldap details of where the user details exists.
In this case i am not using ssl but in case if u are using ssl make sure to add the certificate in the keystores and point that keystore for certificate.
basic details for connecting to LDAP include hostname, port, userdn(i have used cn=root for full priveleges but its better to use an id which has atleast lookup privileges) and password..
In case if u are using the embedded ldap then its better to use "cn=root,secAuthority=Default" as the userdn...
Save the Changes and Deploy...
Now browse to Secure Access Control > Manage > SCIM Configuration....
Select the User Profile Tab..
In the Server Connection select the server connection u created in the above step and in the search suffix and user suffix its best to give the top most OU.
Click on save and if there is any error in the server details that u have provided in the server connections the connection failed error will be displayed..
If all the details are correct and isam is able to communicate to the LDAP then it will give a message to deploy the changes...
Now switch to ISAM User tab in the SCIM Configuration page...
Select the check box for both Enable ISAM Integration and Update Native Users and inthe ISAM User Registry select the Server connection that u have created above.
Save and deploy the changes...
Browse to the Reverse Proxy page and create a junction called /scim junction in the default and mobile webseals with the below details...
Create a transparent junction /scim for both default and mobile webseals with the below values...
Junction - /scim
create transparent path junction - yes
SSL - yes
Target Backend Server hostname - localhost
port - 443
In Basic Authetnication tab select the checkbox for enabling basic authentication and give the credentials for easuser in the username and password field.
HTTP Basic Authentication Header - Filter
headers to be passed - iv-user, iv-groups, iv-creds
set HTTP Header Encoding as none
set Junction Cookie Javascript Block as none
also select the check boxes for Include session cookies and Insert Client IP Addresses
save and it should show a message in blue colour saying junction created successfully.
Edit the Webseal configuration for both the webseals(default and mobile) to make the changes in the configuration file...
In the [filter-content-types] stanza add the following entry:
[filter-content-types]
type = application/scim+json
In the [script-filtering] stanza, enable script filtering and replacing absolute URLs with absolute URLs:
[script-filtering]
script-filter = yes
#rewrite-absolute-with-absolute = no
rewrite-absolute-with-absolute = yes
Deploy and restart the webseals...
Make sure u do these in both the webseals(default and mobile)
Enter the following command to attach an ACL allowing all REST methods to the SCIM endpoint associated with the mobile Reverse Proxy instance
acl attach /WebSEAL/myisam-mobile/scim isam_mobile_rest
Although not strictly required for MMFA, we will also enable all REST methods to the SCIM endpoint associate with the default Reverse Proxy instance. This allows SCIM modify functionality to be demonstrated via the built-in test application. Without this, only GET requests are possible.
acl attach /WebSEAL/myisam-default/scim isam_mobile_rest
Create SCIM admingroup and two users named scimadmin and testuser using the below commands...
group create adminGroup cn=adminGroup,dc=iswga adminGroup
user create scimadmin cn=scimadmin,dc=iswga scimadmin scimadmin Passw0rd
user modify scimadmin account-valid yes
group modify adminGroup add scimadmin
u c testuser cn=testuser,dc=iswga Test User Passw0rd
u m testuser a yes
the above values will change according the type of ldap u are using, in my case i am using the embedded LDAP so the suffix dc=iswga
Test the SCIM configuration using the inbuilt SCIM demo Application...
Browse to Manage System Settings > System Settings > Advanced Tuning Parameters...
Select the new button and Enter scim_demo_enabled as the Key and true as the Value. Click Save Configuration.
Deploy changes using the link in the yellow warning message.
Access the url https://myisam/scim/demo.html
Here myisam refers to the default webseal...
Login with testuser created above using the commands
Now in the general tab check the values being displayed if the values are of the user logged in or not...
click on isam tab and verify if the values being displayed are the values of the user logged in or not...
If these details are correct the SCIM Configuration is Successfull.
Now login back to the VA Admin console and browse to the secure access control > Policy > API Protection...
Click on Create button and create a new API Protection with the below values...
Name : Authenticator
under grant types only enable the check box Authorization Code...
Expand the Token Management section and check the check-box for Enforce single-use authorization grant.
Click Save at the top of the screen.
Deploy changes using the link in the yellow warning message.
Browse to the Clients tab on the API Protection page and create a new client with the below values.
By default the Client ID is a randomly generated string but that complexity is not required here.
Enter AuthenticatorClient as the Client ID.
Enter Authenticator Client as the Client name.
Clear the Confidential checkbox. An MMFA client is generally running on in an untrusted environment (i.e. a mobile device) and so a client secret has little value (and in any case we only want to allow a specific redirect).
Enter the following as the Redirect URI:
https://myisam/mga/sps/mmfa/user/mgmt/html/mmfa/qr_code.html?client_id=AuthenticatorClient
Here myisam refers to the default webseal...
This makes sure that after the OAuth Authorization Grant is generated control is returned to the MMFA registration function.
Enter a company name...in my case i have used IBM as the Company name
and click OK.
Deploy the changes using the link in the yellow warning message
Now Comes the most important part of this exercise the MMFA endpoint configuration.
Navigate to Secure Access Control > Manage > MMFA Configuration.
Click on Wizard to begin configuration.
Set the Client ID to AuthenticatorClient, and the Reverse Proxy URL to https://<ip or hostname of your mobile webseal>:<port on which your webseal is running on>
make sure to give the correct the ip and port, any issues in it will lead to improper configuration and your whole configuration will fail....
Click on Next and it will display the discovery endpoint, token endpoint, HOTP Shared secret Endpoint and TOTP Shared secret endpoint... all these values will be prefilled..
Click on Next and this time it will show the enrollment endpoint and the transaction endpoint..click on next
now it will show the endpoint prefix... all these will be prefilled except the first box...
now click on save and deploy the changes...
Navigate to the Discovery Mechanisms tab on the same page and click Add.
Select urn:ibm:security:authentication:asf:mechanism:mobile_user_approval:fingerprint from the drop-down list and click Save.
Repeat this step to add the following additional mechanisms:
• urn:ibm:security:authentication:asf:mechanism:mobile_user_approval:user_presence
• urn:ibm:security:authentication:asf:mechanism:totp
Navigate to the Custom QR Code Options menu, and click Add.
Enter ignoreSslCerts as the Key and true as the Value.
This option will be added to registration QR codes and instructs IBM Verify that it is OK to connect to SSL endpoints which do not host a valid SSL certificate. You would not set this in a production environment but we need it for our test system.
Click Save and deploy the changes...
Now it is time to test the full configuration....
Access the below url for registering the device...
https://myisam/mga/sps/mga/user/mgmt/html/device/device_selection.html
Here myisam refers to the default webseal...
This page shows all the new authenticators added to the user(i.e) all the devices registered for the user...
Click on Register new Authenticator button...
This will trigger a request to the below url....
https://myisam/mga/sps/oauth/oauth20/authorize?client_id=AuthenticatorClient&response_type=code&scope=mmfaAuthn
Here myisam refers to the default webseal...
if its doesnt redirect then there is an issue with the html file... In case of the upgraded system from an older version to the 9.0.3.0 version the html files will not be updated::::
So browse to Manage System Settings > secure Settings > File Downloads...
Now expand and go to acces control > pages > C > mga > user > mgmt
Download the files design.css, common.js, device_selection.html, device_selection.js and style.css
Now browse to the secure access control > global settings > template files..
expand the C > mga > user > mgmt and delete the files design.css, common.js, device_selection.html, device_selection.js and style.css...
Deploy the changes and now upload the new files that we downloaded from the file downloads option...
design.css, common.js, device_selection.html, device_selection.js and style.css, upload them and deploy the changes...
It generally doesnt sync the new js files that were uploaded.. its better to restart the machine and try the url for device registration again....
After u click on the register new authenticator the page will redirect to a new page which contains the QR CODE...
Now scan the QR Code from the IBM VErify APP in your mobile..(u can download the free ibm verify app from the app store for ios and google play store for andriod devices)
Make sure your mobile can communicate to the webseal (i.e) either your mobile and webseal are in the same network or your webseal is exposed to the internet..
and also for all the dummies out there the app needs internet so please do connect to internet before doing this activity...
A success message is shown saying the device is successfully registered....
in case of error please check ur configurations again...
After it is successfully registered..on your mobile Touch Got it! to continue. You can now set up notifications – this allows IBM Verify to alert you when a new MMFA transaction is pending. Touch Notify Me and then Allow to enable.
You are now offered the option to enable the fingerprint authentication method, provided your device supports it. Touch Use Touch ID to continue (on mobile device). Present you fingerprint when prompted to unlock secure storage.
The fingerprint authentication method will work only onthose devices which have inbuilt finger censor in them...
sadly dowloading fingerprinst secure apps will not work for this..😒
Once it is successfully configured your mobile will show a success message now go to the accounts on your mobile and u will find a new account that got registered with the ipaddress/hostanme of your mobile webseal and the userid shown below that..
clicking on that will show the access code or otp which keeps on changing every 30 or 60 seconds...this can also be used as a otp generator also...i still havent tested this OTP Feature but will test if i can use this otp as a RSA token generator but that is for an other day... 😃
Now go back to the device selection url on your browser ...
https://myisam/mga/sps/mga/user/mgmt/html/device/device_selection.html
Here myisam refers to the default webseal...
it will show the authenticators tab the newly configured device will be shown with an id staring with uuid**********....click on the uuid********* and it will show the details that were obtained from your mobile phone...like the OS VErsion, fingerprint support and other details...
This Completes the device Registration using IBM Verify...
Password Less Login Scenerio using the IBM Verify App:
This scenerio will work based on the userid that is sent in the url..
We will read the username from a username parameter sent in the url to the Authentication Service.
Navigate to Secure Access Control > Policy > Authentication.
On the policies tab click New button to create a new authentication policy.
Enter MMFA Initiate Login Policy as the Name. This is the human-readable name for the policy.
Enter mmfa_initiate_simple_login in the Identifier box. This will be appended to the text already shown which makes the full identifier: urn:ibm:security:authentication:asf:mmfa_initiate_simple_login.
Enter a Description.
Ensure the Enabled checkbox is checked.
An authentication policy consists of one or more steps.
Click Add Step button to add the first step.
Select MMFA Authenticator mechanism from the drop-down list. Then click the properties icon next to it to bring up the properties editor.
In this first example, we will set up the most simple initiate policy possible by using fixed values for most parameters. we can use dynamic values to make things more interesting also and all these can be acheived in Authentication page using a combination of javascripts and authentication mechanism...
.
Select the checkbox next to contextMessage and set the value to Please verify login to myisam. This is the text that will be displayed to the user in the Authenticator Client application.
Select the checkbox next to mode. The default value of Initiate is what we want so don't change it. This tells the mechanism that it is initiating the challenge to the Authenticator Client.
Select the checkbox next to policyURI. Set the value to: urn:ibm:security:authentication:asf:mmfa_response_userpresence
This is Policy ID of the authentication policy that will handle the challenge response from the Authenticator Client. We are going to create this authentication policy in the next step.
The only parameter that is dynamic here is the username parameter. This species the user for which the challenge should be generated. Obviously this needs to be the user that we want to log in. We will read this value from a query string parameter of the request sent to the authentication service. The query string parameter is also named username.
Select the checkbox next to username. Select Request from the drop-down list for Source. This indicates that we will read from the incoming Request.
Enter urn:ibm:security:asf:request:parameter as the Namespace for the value. This is a defined namespace that provides access to query-string parameters of the incoming HTTP request.
Enter username as the Attribute Id. This is the name of the query-string parameter to use.
Click OK to close the parameters window.
Click OK to add the workflow step. Then click Save at the top of the window to save the Policy.
A warning is shown to indicate there is an undeployed change. There is no need to deploy yet though because we have more configuration to do
We have created a authentication policy for sending a request now we need to create another Authentication Policy that will handle the 2nd half of the MMFA process. It performs the challenge/response with the Authenticator Client and then marks the MMFA action complete.
Click the new button to create another new Authentication Policy.
Enter MMFA User Presence Response as the Name.
Enter mmfa_response_userpresence in the box for Identifier.
This makes the complete ID for this authentication policy urn:ibm:security:authentication:asf:mmfa_response_userpresence which matches what we configured as the policyURI in the "initiate" policy.
Enter a Description.
Ensure the Enabled checkbox is checked.
Click Add Step to add the first mechanism to the policy.
The first step in this policy handles the MMFA user presence challenge/response. This uses a pre-defined authentication mechanism called User Presence Approval. Select this from the drop-down list. There are no special properties we need to set.
Click OK to confirm addition of the User Presence Approval mechanism to the policy.
Click Add Step again to add a second step to the policy.
Select MMFA Authenticator from the drop-down list. This is the same mechanism that we used in the "initiate" policy but this time we are going to use it in "response" mode.
Click the properties icon to open the parameters screen.
The only parameter we need to set is the mode. Select the checkbox for mode and set the Value to Response using the drop-down list. This tells the mechanism that it is responsible for completing the MMFA process that was started in the "initiate" policy.
Click OK to close the parameters window.
Click OK to confirm addition of the MMFA Authenicator mechanism to the policy.
Click Save at the top of the window to save the new Authentication Policy.
Deploy changes using the link in the yellow warning message.
Our first MMFA Process is now ready to use. It will be triggered manually by calling the ISAM Authentication Service and requesting the "initiate" policy using its Policy ID.
Setting the Authentication levels:
In this case we will set the mobile login or the password less login mechanism as the higher priority than the password based mechanism...
By default, unauthenticated sessions are level 0, password authentication is assigned level 1 and EAI authentication (which is what the AAC Authentication Service uses) is assigned level 2. In this environment, we want to make MMFA authentication level 1 and password level 2. This requires a change in the Reverse Proxy configuration file.
Navigate to Secure Web Settings → Manage: Reverse Proxy,
Select the radio button for the default Reverse Proxy instance. Click on Manage and select ConfigurationEdit Configuration File from the pop-up menu. This will open the configuration file.
To find a location in this file, use the browser's search function. On Firefox this is activated using Ctrl-f.
Locate the [authentication-levels] stanza and make changes as below.
[authentication-levels]
#----------------------
# STEP UP
#----------------------
# authentication levels
#
# Syntax:
# level = <method-name>
…
#
level = unauthenticated
level = ext-auth-interface
level = password
The order of these levels assigns the authentication levels. With this setting, unauthenticated is 0, ext-auth-interface is 1, and password is 2. This order is important, and is required to allow the ext-auth-interface to be used for step-up authentication in the later advanced password-less login scenario.
Click Save to save the updated configuration.
Deploy changes using the link in the yellow warning message.
Restart the default Reverse Proxy instance.
Access the pdadmin console and execute the below command
acl attach /WebSEAL/myisam-default/mga/websock/mmfa-wss isam_mobile_rest_unauth
object modify /WebSEAL/myisam-default/app set attribute HTTP-Tag-Value AUTHENTICATION_LEVEL=authentication_level
To Test password less login: access the below url
https://myisam/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:mmfa_initiate_simple_login&username=testuser&Target=https://myisam/
Notice that the URL specifies the PolicyId out our "initiate" policy and also provides the user ID of our test user (testuser) in the query string. It also includes a Target parameter which specifies where the user should be sent after successful login.
Select the device that was registered earlier and click Submit.
At this point the Initiate Policy creates an MMFA transaction and displays a "pending" page to the user:
This page is based on a template which can be modified. It includes client-side JavaScript which connects to the transaction status endpoint (via Web Socket) and waits for status updates.
On this page are a set of buttons which trigger actions for the MMFA transaction:
Verify: Polls the authentication service to determine the state of the MMFA process. This can be useful for environments where use of the Web Socket is not possible
Cancel: This cancels the MMFA process. The authentication service returns an error page.
Renotify: This resends the PUSH notification to the authenticator client (asuming PUSH notifications enabled)
Reselect Authenticator: This takes the user back to the device selection page so a different Authenticator client can be chosen to perform the MMFA verification.
now access the verify app in your mobile and click on the sync button (circular button at the top right hand corner) and this is enable a dot on your account...
Select your account now and it will ask for a message saying Please verify login to myisam... click the tick mark and the browser will automatically redirect to the target page...
Now in the above url the target is specified as https://myisam/ this will show be the favicon page...in the same way u can do modifications to you login age to identify here which url the user has requested and reroute that in the browser...
the username is given in the url as testuser...
To change this behaviour u can tweak the authentication policy to accept the username in a request from a html parameter or as a header also...
Now this is the basic method of configuring but this cannot be used in production...we can modify this to a much secure level with some changes to the authentication policy....
We can also add our own javascript to change the way we want this to work...
This method can even be used as a stepup configuration....but will do that all in another post...
For now...thank you and ciao....🙌💃👋
