IBM Security Access Manager: Protect websites with context-based access
Using ISAM security appliances to implement context-based strong authentication for website security
IBM Security Access Manager for Mobile (ISAM for Mobile) allows a security architect to perform context-based authorization (CBA) decisions (also known as risk-based access decisions) on web accesses through the IBM Security Access Manager for Web (ISAM for Web or WebSEAL) security appliance. An important consideration in this design is that a web security architecture is developed that minimizes the number of risk calculations while maintaining a contextually secured web environment.
In this article, we describe the architecture and configuration that is required to configure ISAM for Web and ISAM for Mobile together to allow a CBA risk decision on user authentication to protect a collection of web resources (or an entire site). This architecture ensures that risk calculations are only performed as necessary and not for every subsequent access request.
Figure 1 outlines this architecture.
Figure 1. Architecture of this solution
In order to configure this solution, it is necessary to have the following components:
- An IBM Security Access Manager for Web appliance. This can be either a hardware or software appliance, with V8.0 Fixpack 1 as a minimum. The appliance should be installed with network interfaces configured with an available running WebSEAL reverse proxy instance.
- An IBM Security Access Manager for Mobile appliance. This can be either a hardware or software appliance. The appliance should be installed and activated, with network interfaces configured, with no further configuration performed.
- An application server running the site you wish to protect. This application server should also be capable of some form of active server pages as it will be used as part of the integration. WebSphere, Tomcat, or IIS is suitable.
- A client browser and a smart phone. One that is capable of running a HMAC OTP generator such as Google Authenticator to generate one-time passwords.
In this scenario, we have a web application that requires strong authentication. The web application will be protected by WebSEAL on the ISAM Appliance.
The sample application used in this article is a mock Internet banking website called Your Bank. Within the site, there is a page that is designed for unauthenticated access and a page intended for authenticated access only. This design is common in many online web applications and makes it an appropriate sample application to demonstrate the stronger authentication capabilities of ISAM for Mobile.
Figure 2. Bank website front page
Figure 3. Bank protected page
The site's URL structure is roughly as follows in Table 1.
Table 1. Sample application site's URL structure
|/bank/*||URLs under this folder are designed for authenticated access from regular banking customers.|
|/*||URLs at the site's core are generally designed for access from unauthenticated users.|
In the Download section, we've included the two-page equivalent sample banking web application; it is suitable for running on Tomcat or could be deployed to a WebSphere environment.
Sample security policy
Your Bank has the following security policy requirements:
- All banking customers wishing to access the online Internet banking features must authenticate with a user name and password.
- If customers have not accessed the site from a registered device/browser before, they must additionally authenticate with a one-time password.
- Once the user has authenticated with an OTP, the browser instance is registered.
At its core, this security policy greatly improves the security posture for banking customers since it always requires a form of second-factor authentication to log in. In the user's first interaction with the site, the user is required to enter a user name and a one-time password.
During this initial interaction, the user's browser is fingerprinted and registered.
In subsequent interactions, after a user enters a user name and password, the CBA module in ISAM for Mobile compares the browser fingerprint of the user with previous interactions. If the fingerprint is the same, this provides a second-factor authentication for the user.
This methodology provides greater ease of use for customers, a situation in which they only need to provide an OTP when they are registering a new browser or device. This step can save an organization money by reducing the costs in managing and delivering an OTP SMS strategy.
Now we'll detail the steps taken to configure the ISAM appliances to satisfy the security scenario.
Using the appliances, we introduce the concept of management interfaces and application network interfaces. Administration tasks are performed via the management interface while the runtime communications are performed via the application interfaces. This creates a logical network separation on the devices and allows a better security posture through network separation.
Figure 4. Network interface endpoints
Configure the ISAM appliance to use a local policy server and local registry. You can use a remote LDAP and policy server, but the example provided in this article assumes a local one is used.
Figure 5. ISAM appliance configured with local policy server and LDAP directory
Configure the ISAM appliance with an active reverse proxy instance listening on the application network interface.
Figure 6. ISAM appliance with WebSEAL Reverse Proxy instance configured
ISAM for Mobile basic configuration
In this section we will provide the steps to configure the connection between the ISAM appliance (External Authorization Service plugin) and the ISAM for Mobile appliance (Authorization Service).
Since this example uses a virtual host junction, the hostname localhost mapping to the application interface of the ISAM appliance needs to be made available in your network DNS or set in the hosts file of the MGA appliance for configuration. In order to set the value in the hosts file, on the MGA appliance, navigate to Manage System Settings > Hosts File and add the following value:
- Address: 10.166.1.14
- Hostname: bank.test
Figure 7. Hosts file configuration
The isamcfg configuration tool
The second configuration step requires running the
tool. This tool can be run from the ISAM for Mobile appliance or can be
downloaded from the Manage System Settings > File
Downloads page under /mga/tools/isamcfg. For this
configuration, we are going to run it locally on the ISAM for Mobile
appliance via an SSH command line.
First, SSH using PuTTY or equivalent to the ISAM for Mobile management interface.
Figure 8. PuTTY terminal session to ISAM for mobile appliance
Next, once you're at the menu prompt, navigate to the configuration tool:
isam8> isam isam8:isam> mga isam8:mga> config Security Access Manager Autoconfiguration Tool Version 22.214.171.124 [20141203-1958]
Once the configuration tool has started, begin by selecting the option to
configure both the
Context-based Authorization and the
Authentication Service. This translates into enabling the
WebSEAL instance to be able to call the ISAM for Mobile Appliance for both
CBA decisions and for OTP stronger authentication.
Follow the prompts. (You can replace the bold variables
with the details that match your environment.) Be sure to leave
Context-based Authorization and
Authentication Service selected as
[ X ] in the
isam8> isam Select/deselect the capabilities you would like to configure by typing its number. Press enter to continue: [ X ] 1. Context-based Authorization [ X ] 2. Authentication Service [ X ] 3. API Protection Enter your choice: <Press Enter> Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1
Provide information about the ISAM for Mobile management interface of the ISAM appliances and provide the administration credentials.
Security Access Manager for Mobile Local Management Interface hostname: 10.150.27.149 Security Access Manager for Mobile Local Management Interface port : 443 Security Access Manager for Mobile Appliance administrator user ID [admin]: admin Security Access Manager for Mobile Appliance administrator password: <password> Testing connection to https://10.150.27.149:443/. SSL certificate information: Issuer DN: CN=isam4m Subject DN: CN=isam4m SSL certificate fingerprints: MD5: 7A:93:EB:F4:65:EA:F3:A2:10:37:CD:88:C3:52:FC:3D SHA1: 2A:A2:29:DB:E9:38:C5:0E:ED:27:35:95:0E:F1:B3:06:C6:E2:0D:E9 SSL certificate data valid (y/n): y Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1 Web Gateway Appliance Local Management Interface hostname: 10.150.27.149 Web Gateway Appliance Local Management Interface port : 443 Web Gateway Appliance administrator user ID [admin]: admin Web Gateway Appliance administrator password: <password> Testing connection to https://10.150.27.149:443/. SSL certificate information: Issuer DN: CN=isam4w Subject DN: CN=siam4w SSL certificate fingerprints: MD5: 7E:88:5C:FA:F6:E3:5C:12:D5:72:64:EF:F3:4C:AA:83 SHA1: BB:EA:97:55:25:DC:67:64:01:35:79:F7:E6:27:E0:97:90:A9:1A:84 SSL certificate data valid (y/n): y Instance to configure: 1. wga 2. Cancel Enter your choice : 1 Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1 Security Access Manager administrator user ID [sec_master]: sec_master Security Access Manager administrator password: <password> Security Access Manager Domain Name [Default]: <press Enter to select the default> Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1
Provide information about the application interface of the ISAM for Mobile appliance, including the user name and password for the CBA authorization decision web service (the same web service we tested previously).
Security Access Manager for Mobile application interface hostname: localhost Security Access Manager for Mobile application interface port: 443 Select the method for authentication between WebSEAL and the Security Access Manager for Mobile application interface: 1. Certificate authentication 2. User-id/password authentication Enter your choice : 2 Security Access Manager for Mobile application interface user ID: easuser Security Access Manager for Mobile application interface password: passw0rd <this is the default out-of-the-box password> Testing connection to https://localhost:443. Connection completed. SSL certificate information: Issuer DN: CN=isam, O=ibm, C=us Subject DN: CN=isam, O=ibm, C=us SSL certificate fingerprints: MD5: 79:23:E3:5D:27:DC:66:2B:D2:C5:43:93:10:C4:3E:3F SHA1: F8:08:49:4A:47:CF:92:C2:54:29:EF:24:59:DD:7A:9E:D6:E0:1F:81 SSL certificate data valid (y/n): y Automatically add CA certificate to the key database (y/n): y Restarting the WebSEAL server... Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1 Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1 The following files are available on the Web Gateway Appliance. Choose one for the '400 Bad Request' response page. 1. oauth_template_rsp_400_bad_request.html 2. oauth_template_rsp_401_unauthorized.html 3. oauth_template_rsp_502_bad_gateway.html Enter your choice : 1 The following files are available on the Web Gateway Appliance. Choose one for the '401 Unauthorized' response page. 1. oauth_template_rsp_400_bad_request.html 2. oauth_template_rsp_401_unauthorized.html 3. oauth_template_rsp_502_bad_gateway.html Enter your choice : 2 The following files are available on the Web Gateway Appliance. Choose one for the '502 Bad Gateway' response page. 1. oauth_template_rsp_400_bad_request.html 2. oauth_template_rsp_401_unauthorized.html 3. oauth_template_rsp_502_bad_gateway.html Enter your choice : 3 Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1 The junction /mga contains endpoints that require Authorization HTTP header to be forwarded to the backend server. Do you want to enable this feature? [y|n]? y
isamcfg tool will now configure the WebSEAL ACL's and the
URLs allowing unauthenticated access: https://localhost/mga/sps/static URLs allowing all authenticated users access: https://localhost/mga/sps/ac https://localhost/mga/sps/xauth https://localhost/mga/sps/mga/user/mgmt/html https://localhost/mga/sps/mga/user/mgmt/device https://localhost/mga/sps/mga/user/mgmt/otp Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1 ----------------------------------------------- Planned configuration steps: A junction to the Security Access Manager server will be created at /mga. The POP oauth-pop will be created. The POP rba-pop will be created. ACLs denying access to all users will be attached to: /WebSEAL/isam8-wga/mga ACLs allowing access to all users will be attached to: /WebSEAL/isam8-wga/mga/sps/authsvc /WebSEAL/isam8-wga/mga/sps/xauth /WebSEAL/isam8-wga/mga/sps/authservice/authentication /WebSEAL/isam8-wga/mga/sps/oauth/oauth20/authorize /WebSEAL/isam8-wga/mga/sps/static /WebSEAL/isam8-wga/mga/sps/oauth/oauth20/session /WebSEAL/isam8-wga/mga/sps/oauth/oauth20/token ACLs allowing access to all authenticated users will be attached to: /WebSEAL/isam8-wga/mga/sps/auth /WebSEAL/isam8-wga/mga/sps/ac /WebSEAL/isam8-wga/mga/sps/xauth /WebSEAL/isam8-wga/mga/sps/mga/user/mgmt/html /WebSEAL/isam8-wga/mga/sps/oauth/oauth20/clients /WebSEAL/isam8-wga/mga/sps/common/qr /WebSEAL/isam8-wga/mga/sps/mga/user/mgmt/device /WebSEAL/isam8-wga/mga/sps/mga/user/mgmt/questions /WebSEAL/isam8-wga/mga/sps/mga/user/mgmt/otp /WebSEAL/isam8-wga/mga/sps/mga/user/mgmt/grant EAI authentication will be enabled for the endpoints: /WebSEAL/isam8-wga/mga/sps/oauth/oauth20/session /WebSEAL/isam8-wga/mga/sps/auth /WebSEAL/isam8-wga/mga/sps/authservice/authentication /WebSEAL/isam8-wga/mga/sps/authsvc Certificate authentication will be disabled. HTTP-Tag-Value header insertion will be configured for the attributes: user_session_id=user_session_id Press 1 for Next, 2 for Previous, 3 to Repeat, C to Cancel: 1 Beginning configuration... Attaching ACLs. Creating ACL isam_mobile_nobody. Creating ACL isam_mobile_unauth. Creating ACL isam_mobile_rest. Creating ACL isam_mobile_anyauth. Creating junction /mga. Editing configuration file... Disabling BA authentication. Enabling forms authentication. Restarting the WebSEAL server... Configuration complete.
Note: Make sure you wait about 30 seconds for the WebSEAL server to restart before moving to the next step.
Once the configuration is complete, WebSEAL on the ISAM appliance will have:
- A junction /mga to the CBA and OTP components with ACLs allowing appropriate access
- A POP called rba-pop that can be attached to resources that require context-based access policy
- Both Forms and EAI authentication configured on HTTPS
Configure the communication between ISAM for Mobile and the ISAM for Web Policy Server. This is necessary to attach context-based access policies to ISAM for Web resources. Resources defined on WebSEAL can be visible through the ISAM for Mobile console. Navigate to Secure Mobile Settings > Access Control. Click Resources and then click the Add icon.
Figure 9. View and add WebSEAL resources
The console will prompt for the Policy Server administration credentials; enter the sec_master user name and its password.
Figure 10. Policy Server login details
Click the Add icon again; it should be now possible to browse the resources in the WebSEAL object space.
Figure 11. Browse WebSEAL resources
IBM Security Access Manager user creation
In this section, we will provide the steps to create a sample user in the ISAM appliance local registry.
From the PuTTY terminal used in previous steps, start the ISAM admin
utility. For those familiar with previous versions of ISAM, this is also
pdadmin. Log in with the policy server administrator
sec_master and the configured password.
isam8> isam isam8:isam> admin pdadmin> login Enter User ID: sec_master Enter Password: <password> pdadmin sec_master>
Create a test user
testuser in the local ISAM appliance
pdadmin sec_master> user create testuser cn=testuser,dc=iswga testuser testuser passw0rd pdadmin sec_master> user modify testuser account-valid yes
Note: When using the onboard LDAP server, the suffix is
dc=iswga. This suffix cannot be changed.
ISAM for Web junction creation
In this section we will describe the steps to configure a junction to the sample application. There are a number of alternative mechanisms for creating a junction to the Your Bank server. In the sample environment, the Your Bank Java™ WAR file has been deployed as the ROOT application on Tomcat.
The ISAM appliance introduces junction creation via the Logical Management Interface (LMI) shown here:
Figure 12. Junction management via the LMI interface
Using the LMI, configure a virtualhost junction to your application server by navigating to Secure Reverse Proxy Settings > Reverse Proxy. Choose the instance you wish to add the junction to and click Manage > Junction Management. On the displayed page, click New > Virtual Junction. Under the Junction tab, enter the label bank in the Junction Point Name field.
Figure 13. Create a virtual host junction, part 1
Under the Server tab, add the junction server (Tomcat or equivalent server) hosting the Your Bank site. In the test environment, Tomcat is listening on port 8080 on the server located at 10.166.1.14. The virtual host used will be localhost, listening on WebSEAL port 80 on the application interface 10.150.27.215. Note that if you are using a back-end server that is Virtualhost aware, you should ensure that both the hostname AND port match on both the WebSEAL front end and the back-end server configuration.
Figure 14. Create a virtual host junction, part 2
Configure the junction to send the user name
attribute as a header on the Identity tab.
Figure 15. Create a virtual host junction, part 3
Save the junction when complete. The LMI should now show two junctions listed for the ISAM appliance instance.
Figure 16. Create a virtual host junction, completed
Alternatively, virtual host junctions can still be created via the
traditional admin (
pdadmin) command line interface as used
for the user creation step earlier.
pdadmin sec_master> server task <WebSEAL instance> virtualhost create -t tcp -h 10.166.1.14 -p 8080 -v localhost -c iv-user -p 8080 bank Created Virtual Host Junction at bank
This command creates a junction to our application server, mapping based on the hostname localhost, supplying the user name in the iv-user header.
Host file or DNS configuration
Add an entry to your DNS server or to your local test client computers hosts file to map the ISAM appliance application interface to your defined hostname localhost.
Figure 17. Hosts file example
ISAM for Web configuration steps
This scenario requires a number of changes to the default WebSEAL configuration file. Follow the steps in this section to update the configuration.
First, edit the configuration file: Navigate to Secure Reverse Proxy Settings > Reverse Proxy. Click the Reverse Proxy instance and then navigate to Manage > Configuration > Edit Configuration File.
Figure 18. Configure the Reverse Proxy instance
This will open the traditional WebSEAL configuration file.
Figure 19. WebSEAL configuration file
Next, set the following parameters to enable authentication via HTTP used in this scenario:
- Set this option to enable forms authentication on HTTP.
[forms] #---------------------- # FORMS #---------------------- # Enable authentication using the forms authentication mechanism # One of <http, https, both, none> forms-auth = both
- Set this option to enable EAI authentication on HTTP.
[eai] #---------------------- # EXTERNAL AUTHENTICATION INTERFACE #---------------------- # Enable EAI authentication. # # One of <http, https, both, none> eai-auth = both
Now set the following parameters to enable the mixed handling of standard and virtual hosting junctions used in this scenario:
- Set this option to allow access to the pkmslogout URL without authentication.
[acnt-mgt]... #----------------------------- # ALLOW UNAUTHENTICATED LOGOUT #----------------------------- # Set this parameter to 'yes' to allow unauthenticated users to be able # to request the pkmslogout resource. If this parameter is set to 'no' # an unauthenticated user will be requested to authenticate before the # pkmslogout resource is returned. allow-unauthenticated-logout = yes
- Set this option to allow access to the standard junction /mga through the virtual host junction.
[junction] ... # Two separate junction tables are managed by WebSEAL, one for virtual host # junctions, and the other for standard junctions. When a request is # received the VHJ table is searched first, and if no match is found the # table which manages the standard junctions is then searched. The following # configuration item is used to reverse the search order so that the table # which manages the standard junctions is searched before the VHJ table. match-vhj-first = no
- Set this option to enable authenticated sessions to be shared between standard junctions and virtual host junctions.
[session] ... # Enable a cookie based session to be shared across all standard and virtual # host junctions on a single WebSEAL instance. This is achieved through # enabling the WebSEAL instance to store a single session key as an # independent value in a multi-valued domain cookie, indexed by the instance # name. The domain cookie itself is shared across all participating WebSEAL # instances, but the session values are specific to each instance. # # If WebSEAL exists in an environment where SMS already handles single # sign-on across domains, do not enable this configuration item. shared-domain-cookie = yes
Finally, save the changes to the configuration file, deploy the changes, and restart the reverse proxy instance.
ISAM for Web security policy
By default, WebSEAL will require authentication to access any portion of the protected website. The following commands will modify the security policy to enable unauthenticated access to the application root and require authenticated access to the protected banking pages. It will also allow for unauthenticated access to the attribute-collection process for the CBA risk calculation browser fingerprinting.
Additionally, we attach the authenticated ACL to a resource called /stepup/ on the virtual host junction labeled @bank—this is an application we will use as part of the CBA design and is detailed later.
isam8> isam isam8:isam> admin pdadmin> login Enter User ID: sec_master Enter Password: <password> pdadmin sec_master> acl attach /WebSEAL/<WebSEAL instance>/@bank/ isam_mobile_unauth pdadmin sec_master> acl attach /WebSEAL/<WebSEAL instance>/@bank/bank/ default-webseal pdadmin sec_master> acl attach /WebSEAL/<WebSEAL instance>/@bank/stepup/ default-webseal pdadmin sec_master> server replicate
With this basic security policy, if we navigate to the ISAM appliance application interface, the Your Bank website should be presented without requiring any authentication credential and anything under the /bank folder will be protected with forms-based authentication.
Figure 20. Bank application via WebSEAL junction
Next, we will define a security policy that requires an authentication level of 2 to access the /bank folder. The first step is to define a Protected Object Policy (POP) that requires level 2 authentication.
pdadmin sec_master> pop create level2 pdadmin sec_master> pop modify level2 set ipauth anyothernw 2
Now we attach this to our banking resource.
pdadmin sec_master> pop attach /WebSEAL/<WebSEAL instance>/@bank/bank level2
With the configuration of level 2 authentication required to access the banking site, we must now configure a mechanism whereby a user can attain a level 2 credential. For this purpose we will use a very simple EAI JSP page that simply returns a level 2 authentication with no user interaction.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <%@page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" import="java.util.Enumeration"%> <html> <head> <title>Stepup</title> <meta http-equiv="pragma" content="no-cache" /> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <% String URL = request.getParameter("URL"); String username = request.getHeader("iv-user"); /* This is where the EAI returns the authenticated user, * and the higher level authentication credential. */ response.setHeader("am-fim-eai-user-id", username); response.setHeader("am-eai-auth-level", "2"); if (URL != null) response.setHeader("am-fim-eai-redir-url", URL); %> </head> </html>
A sample WAR file containing this JSP page is available from the Download section.
With the configuration of ISAM for Mobile into the ISAM appliance, the WebSEAL EAI interface is already partly configured for these purposes. Two steps remain.
First, set this application URL as a WebSEAL EAI trigger URL. On the ISAM appliance administration interface, navigate to the Reverse Proxy instance:
- Navigate to Secure Reverse Proxy Settings > Reverse Proxy. Select the reverse proxy instance and click Edit.
- On the Authentication tab, add a new trigger URL for the EAI application.
Figure 21. Add trigger URL to the ISAM Appliance Reverse Proxy configuration
- Click Save to save the changes.
Now configure the step-up HTML template to redirect to the step-up application:
- With the reverse proxy instance still selected from the earlier step, click Manage > Management Root to view the template pages.
Figure 22. Edit the stepup.html template page
- Locate the stepuplogin.html file management > C > stepuplogin.html.
- (Optional) Back up the existing page by clicking Manage > Export to save to your local computer.
- Edit the file, replace with the following HTML.
Attribute collection fingerprints the browser based on the risk profile selected. This is explained in more detail in the Context-based authorization policy definition section.
Note: So that you can see this page load in your browser, there is an intentional 3 second delay.
Once the attribute collection completes, it will redirect to the step-up application deployed on the application server located under the /stepup/ folder. A version of this template file has been included in the Download section.
Finally, once configured, save and deploy the changes and restart the reverse proxy instance.
Security policy test
Attempting to access the
/bank resources now, WebSEAL should
now prompt for a user name and password forms-based authentication, which
would authenticate the user to a level 1 authentication. WebSEAL will then
enforce the POP security policy that requires users are authenticated to
level 2, then redirect to the step-up template page. The step-up template
page will redirect the browser to access the step-up EAI, which will
upgrade the credential to a level 2 credential, then redirect back to the
/bank site —satisfying the security policy.
Figure 23. Sequence diagram of security policy test
Acquire second-factor one-time password credential
The ISAM for Mobile appliance introduces a range of capabilities for OTP generation and delivery. For this demo environment, the easiest to demonstrate is the HMAC-based one-time password (HOTP) mechanism. For other OTP credentials, please see the ISAM for Mobile Information Center for configuration details.
Next, through your ISAM appliance protected application interface, navigate to the MGA junction to acquire your testuser's HOTP secret shared key.
Authenticate when prompted and with your mobile, capture the HOTP barcode. Note that there are two barcodes displayed, so be sure to use the one labeled HOTP. HOTP is a counter-based software token, useful in virtualized testing environments since clock synchronization is not required.
Figure 24. Scan HOTP QR code with Google Authenticator
Context-based authorization policy definition
In this section, we will walk you through the steps to set up silent device registration and step-up authentication that will use the HMAC one-time password authentication.
First, open the ISAM for Mobile administration Logical Management Interface.
Next, modify the risk profile to use for calculating the risk score. For this scenario, we will use the Browser profile:
- Navigate to Secure Mobile Settings > Risk Profiles.
Figure 25. Configure the Active Risk Profile
- Click the Browser profile and click Set Active.
Figure 26. Set the Browser Profile Active
- Once it is set to Active, a prompt will appear to deploy the changes. Deploy the changes now.
Figure 27. Deploy the changes
Note: This make take a few moments, since this change requires a runtime restart.
The next step is to navigate to Secure Mobile Settings > Access Control.
After that, create a new policy by clicking the + icon on the Policy table.
Figure 28. Create a new policy
Now create a policy that triggers HOTP and device registration:
- Give the policy a name such as Silent Device Register with HOTP and a description.
Figure 29. Enter policy name and description
- Click Add Rule and create part one of the policy that looks like the one in the following figure.
Figure 30. Policy authoring, part 1
In the first part of the rule, we define a policy that deals with users
that have authenticated with a user name and password but have not
accessed the site with this browser before. This is identified as a low
authentication level, level 1, and they have a
is greater or equal to 55. Since we have configured the browser-based risk
riskScore is calculated based on a browser
fingerprint. On this access, we will redirect them to the HOTP process
with the HOTP authentication.
Click OK to complete the first part of the rule.
- Click Add Rule and create the second part of the policy that looks like the following figure.
Figure 31. Policy authoring, part 2
In the second part of the rule, we define a policy that deals with users
that have authenticated with a user name and password, with an
unregistered browser and have completed their OTP flow. This is identified
authenticationTypes, which doesn't have a member
urn:ibm:security:authentication:asf:hotp, and they have a
riskScore that is still high (>55). On this access, we will
permit access with Silent Device Registration.
Click OK to complete the second part of the rule.
- Click Add Rule and create the third part of the policy that looks like the following figure.
Figure 32. Policy authoring, part 3
In the third part of the rule, we define a policy that deals with the users
that have authenticated with a user name and password and with a
registered browser. This is identified by the low
of below 55. On this access, we simply permit access.
Click OK to complete the third part of the rule.
- Click Save to save the policy.
The complete policy should looks like the following screen capture:
Figure 33. Complete policy
The next step is to create a new resource and attach the new policy:
- Click Resources, then click the + icon to add an available resource.
Figure 34. Create a new resource point
- Define a resource that maps to the step-up EAI application on the virtual host.
Figure 35. Define the step-up resource point
- With the step-up resource selected, click Attach to attach the Silent Device Register with HOTP policy. Select the policy and click OK.
Figure 36. Attach the Silent Device Register with HOTP policy, part 1
Figure 37. Attach the Silent Device Register with HOTP policy, part 2
- Click Publish to deploy the policy.
Figure 38. Publish the policy
With this policy established, the ACLs and POPs configured, the site should now be protected with true two-factor authentication. The following chart describes the flows.
Figure 39. CBA two-factor authentication to protect the /bank website
Managing registered devices
Registered devices can be managed by both end users and system administrators.
When authenticated through WebSEAL, a user can navigate to the following URL to see his registered devices.
Figure 40. Device list
In this way, the sample banking website included in the demo can list the registered devices.
Figure 41. Device list integrated into the Your Bank site
Administrators can manage users' registered devices through the ISAM for Mobile LMI.
- Navigate to Secure Mobile Settings > Devices.
Figure 42. Administration of users' registered devices
- Search for the user; the wildcard * can be used.
Figure 43. List and manage a user's devices
We've shown you how to securely protect two-factor authentication across a WebSEAL-protected site by integrating and configuring IBM Security Access Manager for Web and IBM Security Access Manager for Mobile. We've also demonstrated how to use ISAM for Mobile's context-based access and one-time password (OTP) interface to enable you to apply intelligent stronger authentication access decisions across an organization's website. The short video demo in this section illustrates the completed scenario.
- Visit the Security n developerWorks blog to learn about new security-related how-to guides, articles, and demo videos.
- Follow @dwsecurity to get updates from the developerWorks security zone in real time.