Had a request recently to handle a partially authenticated state when the inbound user is either missing attributes, or needs to select from multiple mapped accounts when accessing resources protected by ISAM or what is now IBM Security Verify Access.
To do this, we simply authenticate the user into a ‘semi-authenticated’ or low level authenticated state, that demands completion of an additional authentication flow (or profile enrichment) to complete.
The diagram above describes the flow that can be used to mitigate this problem.
It all pivots around the decision on inbound authentication, as to whether the inbound assertion has the required attributes or whether the user has a unique account to map to locally. This article doesn’t capture every step, there is still some work to do on your own, but hopefully the steps captured here mean there are few ‘leaps’ required to achieve this.
Adding an Authentication Level to the inbound SAML request
In the SP Mapping rule, you can use whatever logic you require to detemine the outcome of the decision above. For example if attributes are missing, incomplete, or not matching a certain regex, then require user input. From there, you can then use some of the following code to set the authenticated state to the SAML Login.
//Add any important attributes to returned credentialvar testAttr = new Attribute("testattr_sp","urn:mytype", "myvalue_sp");
stsuu.addAttribute(testAttr);
// add AUTHENTICATION_LEVEL 2
var authnLevel = new Attribute("AUTHENTICATION_LEVEL","urn:ibm:names:ITFIM:5.1:accessmanager", "2"); stsuu.addAttribute(authnLevel);
// set this target override if you don't have eai-redir-url-priority=no in webseal config file at the idpproxy
var authnLevel = new Attribute("itfim_override_targeturl_attr","urn:ibm:names:ITFIM:5.1:accessmanager", "/someurltogotoafterthiscompletes");
stsuu.addAttribute(authnLevel);
Protect the resources on your site with different authentication levels
Define a security policy that requires an authentication level of 2 to access the /protected URLs in your site. 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 resource(s).
pdadmin sec_master> pop attach /WebSEAL/<WebSEAL instance>/protected level2
Redirect to an application that asks for more information
Using selective local response redirect (discussed more here) we can redirect to a specific URL when a stepup operation is required. Enable it like so:
#--------------------------
# LOCAL RESPONSE REDIRECTS
#--------------------------
# Enable/disable sending a redirect instead of serving management or error
# pages from the local system.
#
# The local-response-redirect-uri parameter must be set in order for this
# option to function.
#
# This configuration item may be customized for a particular junction
# by adding the adjusted configuration item to a [acnt-mgt:{jct_id}] stanza,
# where '{jct-id}' refers to the junction point for a standard junction
# (include the leading '/'), or the virtual host label for a virtual host
# junction.
enable-local-response-redirect = yesThen configure the URI’s for the desired operation:
[local-response-redirect]
# URLs to which management page requests are redirected. All management
# requests will be redirected to the URLs with a query string indicating
# the operation requested, along with any macros (as configured in the
# [local-response-macros] stanza). See the WebSEAL Admin Guide for the
# specific format of the query string, and how the receiving handler should
# treat the requests.
local-response-redirect-uri = [stepup] /mga/sps/authsvc?PolicyId=yourauthsvcpolicythattakesmoreinfoReturn Authentication level upon completion of the Authsvc policy
In the AuthsvcCred Mapping rule – the mapping rule that runs upon completion of every authentication service flow, set the new authentication level (also discussed here):
importClass(Packages.com.tivoli.am.fim.trustserver.sts.uuser.Attribute);
importPackage(Packages.com.tivoli.am.fim.trustserver.sts.utilities);
//Optional Trace String - with trace string: com.tivoli.am.fim.trustserver.sts.utilities.*=all
//IDMappingExtUtils.traceString("AuthSvcCred mapping rule called with stsuu: " + stsuu.toString());
var stsuuAttrs = stsuu.getAttributeContainer();
var policyID = context.get(Scope.SESSION, "urn:ibm:security:asf:policy", "policyID");
if (policyID.equals( "urn:ibm:security:authentication:asf:yourpolicyid")) {
stsuuAttrs.setAttribute(new Attribute("AUTHENTICATION_LEVEL", null, "2"));
}This can also be done using the UI in the Authentication Service, here:
How do you write the profile page?
This is an example that simply authenticates the user, you should be able to easily modify this to suit your environment/needs.
The main addition might be a check to ensure that they haven’t already satisfied this check, with a validation of the authentication level before operation.
The authentication level of the inbound request can be achieved using the following JavaScript:
var result = context.get(Scope.REQUEST,"urn:ibm:security:asf:request:token:attribute", ”AUTHENTICATION_LEVEL");Note, this could also be easily protected from the reverse proxy, if you’re taking advantage of the URL Based Authentication service kickoff.
What about account selection?
If you wanted to determine which account a user should authenticate as? For example if a broker in your organisation represents several internal identities, then you need to take them to an account selection page. This is also easily achieved in an infomap mechanism, the trick is to authenticate them to a dummy user at authentication level 1, with their identity captured in their credential attributes for deduplication via the UX.
For the customer I was working with, I quickly modified my any alias login, to demonstrate the user identity swap via the authentication service.
importPackage(Packages.com.tivoli.am.fim.trustserver.sts.utilities);
importClass(Packages.com.ibm.security.access.user.UserLookupHelper);
importClass(Packages.com.ibm.security.access.user.User);
importClass(Packages.com.tivoli.am.fim.trustserver.sts.utilities.IDMappingExtUtils);
var username = context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "username");
var password = context.get(Scope.REQUEST, "urn:ibm:security:asf:request:parameter", "password");
var oldusername = context.get(Scope.REQUEST, "urn:ibm:security:asf:request:token:attribute", "username")
if(username == null || password == null) {
//This is likely the first time through
//Display the default template page here -
//to challenge for the username and password
macros.put("@ERROR_MESSAGE@", "Old User is " + oldusername);
success.setValue(false);
} else {
context.set(Scope.SESSION, "urn:ibm:security:asf:response:token:attributes", "username", username)
success.setValue(true);
}
And instantiated this as an infomap mechanism with the basic login.html template page.
/authsvc/authenticator/password/login.html
The reverse proxy can enforce that the users account doesn’t change on EAI Login flows, this enforcement can be relaxed with the following configuration.
[step-up]
#
# The following entry determines, in the event of a step-up operation,
# whether the new user ID must match the user ID from the previous
# authentication. In the situation where verify-step-up-user = yes,
# and the user IDs do not match, an error will be presented to the user.
#
verify-step-up-user = no
There are a few other things to consider, whether you’re using standard ISAM Users, External Users, or PAC Based authentication in your authentication service response, this is all handled in the point of contact configuration panel.
If you’re looking to do all of this in one authentication service policy, also take a look at the recently released branching authentication experience in the authentication service. (Also sometimes call “tree” based authentication)
Philip Nye 