The ISAM authentication service
performs initial and step-up authentication by either browser or API
When using the authentication service it is invoked with one of three parameters to identify the request context, both when starting a new authentication event, or continuing one:
TransactionId - Which is used when a context based access policy triggers an authentication service transaction.
PolicyId - Used to initiate a new authentication service transaction with a selected policy
StateId - Used to continue an already initiated authentication service transaction.
The focus of this blog is initiation of authentication service policy via a
and some changes which were made in 220.127.116.11
is a URN
, with a prefix unique to the authentication service. An example of a policy ID is:
In this screenshot we can see the 'identifier', the policyId is:
This initiates the out of the box username & password authentication mechanism. All policy IDs have the prefix
, with the final portion being unique to the policy.
An example of initiating a authentication service flow using the above
HTTP GET https://www.myidp.ibm.com/isam/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:password
Prior to 9060 the only way which a policy could be presented to the authentication service was via the post or query string parameter
. This is of note as the
is not part of the web object, but is instead just a parameter to the authentication service. This makes attaching an ACL or POP to a given policy not possible without using DynURL
In 9060 a new capability to the authentication service was added. A third way to present a
was added. This takes the form of a new path and a path parameter based off the configured identifier.
This lets the same policy password policy'
be invoked with the following request instead:
HTTP GET https://www.myidp.ibm.com/isam/sps/authsvc/policy/password
This is a shorter, and more discrete URL. Further more the policy identifier is provided as a path parameter, meaning an ACL or POP can easily be attached to the endpoint in the traditional manner. This offers finer granularity to which parts of the authentication service are available depending on whether or not the user is authenticated, or what groups they are a member of.
This capability is enabled via an advanced configuration
. This configuration can be set to one of 3 values which allows for different modes of operation:
parameter - The prior to 9060 function, does not enable this enhancement. This is the default value.
path - Enables the new kickoff method and does not allow a PolicyId to be presented via parameter
both - Allows for operation of both methods, which is useful when migrating.
When using the authentication service with this new feature, there are a few things to be aware of:
- The path parameter is under a new object "policy"
PolicyId is shortened, its no longer a URN and is instead just the unique portion of the policy identifier is used.
When working through a given policy, the URL will remain the policy URI, but will be accessed with a
for the current phase of the flow. An example of this is:
This means that in the event of a session timing out, or an invalid
Most of the use cases for this feature are highly practical, consider a policy which you only want to enable users of a certain group to invoke, by attaching a group-based ACL to the policy endpoint access to that policy is now restricted.
Consider this feature when deploying the authentication service and take a stricter security posture by only allowing users to invoke the policies they need access to.