Contents


IBM Security Access Manager: Protect websites with context-based access

Using ISAM security appliances to implement context-based strong authentication for website security

Comments

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
Architecture of this solution
Architecture of this solution

Solution design

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.

Sample application

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
Bank website front page
Bank website front page
Figure 3. Bank protected page
Bank protected page
Bank protected page

The site's URL structure is roughly as follows in Table 1.

Table 1. Sample application site's URL structure
URL pattern Purpose
/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.

Configuration steps

Now we'll detail the steps taken to configure the ISAM appliances to satisfy the security scenario.

Network interfaces

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
Network interface endpoints
Network interface endpoints

ISAM appliance

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
ISAM appliance configured with local policy server and LDAP directory
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 appliance with WebSEAL Reverse Proxy instance configured
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).

Hostname resolution

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
Hosts file configuration
Hosts file configuration

The isamcfg configuration tool

The second configuration step requires running the isamcfg 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
PuTTY terminal session to ISAM for mobile appliance
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 8.0.1.0 [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 configuration tool.

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]: 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]: 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]: 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 [1]: 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]: 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 [1]: 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 [1]: 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

The isamcfg tool will now configure the WebSEAL ACL's and the EAS POP.

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
View and add WebSEAL resources
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
Policy Server login details
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
Browse WebSEAL resources
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 known as 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 registry.

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
Junction management via the LMI interface
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
Create a virtual host junction, part 1
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
Create a virtual host junction, part 2
Create a virtual host junction, part 2

Configure the junction to send the user name iv-user the attribute as a header on the Identity tab.

Figure 15. Create a virtual host junction, part 3
Create a virtual host junction, part 3
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
Create a virtual host junction, completed
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
Hosts file example
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
Configure the Reverse Proxy instance
Configure the Reverse Proxy instance

This will open the traditional WebSEAL configuration file.

Figure 19. WebSEAL configuration file
WebSEAL configuration file
WebSEAL configuration file

Next, set the following parameters to enable authentication via HTTP used in this scenario:

  1. 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
  1. 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:

  1. 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
  1. 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
  1. 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
Bank application via WebSEAL junction
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

Step-up application

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:

  1. Navigate to Secure Reverse Proxy Settings > Reverse Proxy. Select the reverse proxy instance and click Edit.
  2. On the Authentication tab, add a new trigger URL for the EAI application.
http://bank.test/stepup/*
Figure 21. Add trigger URL to the ISAM Appliance Reverse Proxy configuration
Add trigger URL to the ISAM Appliance Reverse Proxy configuration
Add trigger URL to the ISAM Appliance Reverse Proxy configuration
  1. Click Save to save the changes.

Now configure the step-up HTML template to redirect to the step-up application:

  1. 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
Edit the stepup.html template page
Edit the stepup.html template page
  1. Locate the stepuplogin.html file management > C > stepuplogin.html.
  2. (Optional) Back up the existing page by clicking Manage > Export to save to your local computer.
  3. Edit the file, replace with the following HTML.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title>Fingerprinting Browser...</title>
<script src="/mga/sps/ac/js/info.js">
</script>
</head> 
	<body> 
		<form action="/stepup/" method="post"> 
			<input type="hidden" name="URL" value="%URL%" /> 
		</form>
<script TYPE="text/javascript"> 
	var loginText = 'Fingerprinting Browser - Please wait...<br>' + 
		'Note, this page contains an intentional delay of 3 seconds.'; 
	document.write(loginText); 
	// Set the parameter '3000' to '0' to remove the 3 second delay. 
	setTimeout('document.forms[0].submit()', 3000);
</script> 
</body>
</html>

This page will load the attribute collection JavaScript file:

http://bank.test/mga/sps/ac/js/info.js

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
Sequence diagram of security policy test
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.

With your mobile phone download and install a TOTP- or HOTP-capable mobile application. For this test, we used Google Authenticator [download for iOS | download for Android ].

Next, through your ISAM appliance protected application interface, navigate to the MGA junction to acquire your testuser's HOTP secret shared key.

https://bank.test/mga/sps/mga/user/mgmt/html/otp/otp.html

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
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:

  1. Navigate to Secure Mobile Settings > Risk Profiles.
Figure 25. Configure the Active Risk Profile
Configure the Active Risk Profile
Configure the Active Risk Profile
  1. Click the Browser profile and click Set Active.
Figure 26. Set the Browser Profile Active
Set the Browser Profile Active
Set the Browser Profile Active
  1. Once it is set to Active, a prompt will appear to deploy the changes. Deploy the changes now.
Figure 27. Deploy the changes
Deploy the changes
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
Create a new policy
Create a new policy

Now create a policy that triggers HOTP and device registration:

  1. Give the policy a name such as Silent Device Register with HOTP and a description.
Figure 29. Enter policy name and description
Enter policy name and description
Enter policy name and description
  1. 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
Policy authoring, part 1
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 riskScore that is greater or equal to 55. Since we have configured the browser-based risk profile, this 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.

  1. Click Add Rule and create the second part of the policy that looks like the following figure.
Figure 31. Policy authoring, part 2
Policy authoring, part 2
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 as their 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.

  1. Click Add Rule and create the third part of the policy that looks like the following figure.
Figure 32. Policy authoring, part 3
Policy authoring, part 3
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 riskScore of below 55. On this access, we simply permit access.

Click OK to complete the third part of the rule.

  1. Click Save to save the policy.

The complete policy should looks like the following screen capture:

Figure 33. Complete policy
Complete policy
Complete policy

The next step is to create a new resource and attach the new policy:

  1. Click Resources, then click the + icon to add an available resource.
Figure 34. Create a new resource point
Create a new resource point
Create a new resource point
  1. Define a resource that maps to the step-up EAI application on the virtual host.
Figure 35. Define the step-up resource point
Define the step-up resource point
Define the step-up resource point
  1. 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
Attach the Silent Device Register with HOTP , part 1
Attach the Silent Device Register with HOTP , part 1
Figure 37. Attach the Silent Device Register with HOTP policy, part 2
Attach the Silent Device Register with HOTP policy, part 2
Attach the Silent Device Register with HOTP policy, part 2
  1. Click Publish to deploy the policy.
Figure 38. Publish the policy
Publish the policy
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
CBA two-factor authentication to protect the /bank website
CBA two-factor authentication to protect the /bank website

Managing registered devices

Registered devices can be managed by both end users and system administrators.

Web/REST interface

When authenticated through WebSEAL, a user can navigate to the following URL to see his registered devices.

http://bank.test/mga/sps/mga/user/mgmt/html/device/device_selection.html
Figure 40. Device list
Device list
Device list

This page's appearance and functionality can be modified through the ISAM for Mobile template pages. The data on this page is populated by JavaScript from the REST interfaces.

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
Device list integrated into Your Bank site
Device list integrated into Your Bank site

Administration interface

Administrators can manage users' registered devices through the ISAM for Mobile LMI.

  1. Navigate to Secure Mobile Settings > Devices.
Figure 42. Administration of users' registered devices
Administration of users' registered devices
Administration of users' registered devices
  1. Search for the user; the wildcard * can be used.
Figure 43. List and manage a user's devices
List and manage a user's devices
List and manage a user's devices

In conclusion

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.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Security, Mobile development
ArticleID=1023917
ArticleTitle=IBM Security Access Manager: Protect websites with context-based access
publish-date=12212015