Information Technology Reference
In-Depth Information
multiple incarnations and engagements of the same physical user over a
multi-year horizon.
Adopt a simple model for user roles and keep IAM's role-based access
control tables relatively coarse-grained (e.g., application-level access
rights only). Finer-grained roles within IAM to control access to
application functions are neither necessary nor practical.
Access Management:
Choose CAS (JA-SIG's Central Authentication Service product) as the
heart of the Access Management solution. This is a ticket-based Single
Sign-On system based on the Kerberos architecture but specially tuned
for web applications. (We'll cover non-web applications later.)
Shibboleth is a good choice for a federated identity solution, and we will
describe its use in some detail.
There is a wide choice of interceptors. CAS provides a servlet filter that
you can simply configure and bundle with every web application. Or you
can set up an authenticating reverse proxy that is common to a group of
applications. There are other options as well.
Identity Management:
Expose user administration functions as simple REST-based services.
Upstream “sources of truth” for user data such as HR applications and
resource management systems should initiate user provisioning/de-
provisioning and the grant and revocation of user access rights by
invoking these services. You can secure access to these HTTP-based
services using IAM's own Access Management capability.
Build simple user administration screens using an agile toolkit of your
choice (e.g., Grails, Roo) that can also reuse these REST services.
The invocation of REST services and the use of user administration
screens may require “user events” to be generated downstream in
addition to local updates to the IAM directory and database.
The interaction between upstream systems and IAM need be no more
complex than synchronous request/response. However, the interaction
between IAM and downstream systems needs to be asynchronous and
