Information Technology Reference
In-Depth Information
is when they are combined with applications. For example, if the IAM
protects an ERP system and an HR system, then we may have 6 “application
roles” in all (ERP Administrator, ERP User, ERP Read-Only User, HR
Administrator, HR User and HR Read-Only User). These are the roles that will
be granted access to applications. Two role types that are useful for IAM in
particular are “Requester” and “Authoriser”. Auditors like to ensure that
user management functions are initiated (requested) by one user and
authorised by another.
Tip 4
: Build support for coarse-grained access control, not fine-grained
When stakeholders hear that you are building an IAM, there will be pressure
on you to incorporate support for everything they can think of, including the
proverbial kitchen sink. One of the really insidious requirements is fine-
grained access control. An example of this is the expectation that IAM will
control the specific screens and buttons that a user can access within an
application. But, looking ahead to the day IAM protects a dozen or more
applications, each with its specialised roles and functions, it is clearly a very
complex undertaking to try and hold all those various application-specific
roles and functions and map the allowed accesses within tables of the IAM
database. It gets even worse because applications change their local roles
and functions fairly frequently, so IAM will end up having to stay current
with the requirements of every application in the ecosystem. This is a largely
infeasible task, and allowing fine-grained access control to be part of IAM is
asking for trouble. Resist such pressure strongly. IAM cannot manage fine-
grained function or data access. The most it can do is protect applications
themselves as coarse-grained units from unauthorised access. It can also
pass in user attributes to these applications as part of the initial access, so
applications are free to apply more fine-grained access control logic
internally.
Getting the granularity of Role-Based Access Control right is one of the
crucial decisions in determining the success of IAM
40
.
40
Some companies have a more sophisticated HR practice that defines an enterprise-
wide “Job Family Framework” or JFF. If an organisation has no more than 50-100
generic roles that are mapped to specific job titles in individual divisions and
departments, then it becomes feasible for IAM to manage this reasonable number of
generic roles in its own database. It may be possible to extend the authorisation logic
of IAM to include a rules engine that considers the user's JFF role and their
department to arrive at more refined judgements of access rights to business
functions. In the absence of a JFF, we recommend that IAM stick to coarse-grained
roles (I.e,. whether allowed to access an application or not) and leave the individual
applications to enforce finer-grained access control logic.
