I was recently involved in an engagement where I was required to re-visit the topic of Tivoli Access Manager authorization rules. For the un-initiated, authorization rules are a form of policy template (just like ACL’s and POP’s) that can be used in Tivoli Access Manager to define an authorization requirement on a protected object (e.g. on a URL in Tivoli Access Manager for eBusiness WebSEAL).

Authorization rules differ from ACL’s and POP’s in that they can be defined in terms of “variables” (known as Access Decision Information, or ADI) that might appear in the credential, or be retrieved externally at runtime via an entitlements service. A good example of when an authorization rule might be your best policy template choice if when you wish to enforce an authorization decision on dynamic authentication-time or runtime data.

When a TAM authorization application (such as WebSEAL) prepares to do rule evaluation, it collects vairable information from several sources, in order. These include the azn engine itself, the TAM credential, the resource manager (e.g. WebSEAL), and any configured entitlements services. Configured entitlements services are called last to provide values for any yet unevaluated ADI. If at the end of mining information from all these sources there are any ADI that don’t yet have a value, then rule evalation with always fail.

Sometimes this is not a desirable outcome. For example, consider a WebSEAL installation that has switch-user capability for helpdesk administrators to login as another regular TAM user. You may have an authorization requirement for a particularly sensitive application (e.g.to look at your salary) that says that regularly logged in users can access the application, but administrators that are logged in as that user via switch-user may not. One of the only reliable ways to determine if an administrator is logged in via switch-user, is to check for the prescense of the “tagvalue_su-admin” attribute in the credential. If this attribute is present, then you would like to deny access, otherwise you would allow access. This is not a straight forward rule to write with TAM authorization rules because you cannot check for the absence of an attribute (the rule will fail to evaluate since the ADI could not be populated).

To solve this type of problem I recommend you employ a “catch-all” entitlements service that is configured last in the azn application’s configuraiton file (webseald-default.conf for a default installation of WebSEAL). This entitlements service returns something like “NO_VALUE” for each ADI that doesn’t yet have a value. Then you can code your authorization rule to look like:

<xsl:choose> 
  <xsl:when test="/XMLADI/tagvalue_su-admin = 'NO_VALUE'">!TRUE!</xsl:when> 
  <xsl:otherwise>!FALSE!</xsl:otherwise> 
</xsl:choose> 

I’ve prepared source code here for an example entitlements service that you can download and compile in a TAM environment. There is a lot of printf’s in there to show you what’s going on. In fact most of the file is verbose printouts. If you run WebSEAL in the foreground you will see these as debug information, and you’ll want to take them out for a production environment. To configure WebSEAL to use the entitlements service, modify the conf file to include:

[aznapi-configuration] 
dynamic-adi-entitlement-services = novalue 

[aznapi-entitlement-services] 
novalue = azn_ent_novalue 

The azn_ent_novalue.dll (or .so, .a, etc depending on platform) should be placed in the system path.

Similarly, I’ve also had requests for interesting time-sensitive authorization. For example users in group9_to_5 can access this application from 9 to 5, but users in group_whenever can access the application at any time. You cannot implement this authorization requirement with a simple time-of-day POP since the time of day requirement is specific to the group membership. It can however be done with an authorization rule, and an entitlements service which can provide you with the current time of day. Here’s source code for a time entitlements service that populates ADI for this type of authorization rule:

<xsl:choose>
    <xsl:when test="azn_cred_groups = 'group9_to_5' and number(adi_hour) > 8 and number(adi_hour) < 17">
        !TRUE!
    </xsl:when>
    <xsl:when test="azn_cred_groups = 'group_whenever'">
        !TRUE!
    </xsl:when>
    <xsl:otherwise>
        !FALSE!
    </xsl:otherwise>
</xsl:choose>

More information on TAM authorization rules is available in the Tivoli Information Center here.