TEC Workbook - IBM

IBM Software
4.3 Credential and resource mapping
Successful server-based authentication generates a set of credentials attesting to the service requester’s
identity. These credentials can then be mapped into another set more appropriate for the authorization
method selected. In addition, the extracted resource name can also be optionally mapped to something
more appropriate for the authorization method selected.
The resulting credentials, along with the resulting resource name, form the basis for client authorization,
which determines if the now identified client has access to the requested resource.
4.4 Authorize
Like authentication, authorization is most commonly accomplished via an external policy server such as
Tivoli Access Manager or an LDAP. The result of the authorization phase is to either allow or deny the
request to proceed.
If either authentication or authorization denies access, the system generates an error which is returned to
the calling entity. This error may be handled, as with any other errors within multi-step processing, by an
on-error action or an error rule. Either method allows for the creation of custom error messages.
4.5 Audit & accounting
The final phase of the AAA policy performs auditing and security mediation tasks such as converting
between WS-Security UsernameToken element and Kerberos/SPNEGO. This phase has the ability to
generate various types of security tokens, including Kerberos/SPNEGO, LTPA, and SAML assertions. A
stylesheet can also be identified for execution to do any custom auditing tasks.
4.6 LDAP authentication
In this section, you’ll add an AAA action to your processing rule to authenticate requests against an
LDAP.
__1. Re-open the policy editor by clicking on the ellipsis button in the Multi-Protocol Gateway Policy
field.
__2. In the Client-to-Server rule, drag an AAA action and drop it after the initial match action.
Page 70 WebSphere Lab Jam