NOTE Chapter 9 discusses the Oracle Directory Management story in more detail and shows how you can apply OID and OVD together and independently to solve the basic challenges of creati
Trang 1374 Part III: Identity Management
FIGURE 8-7 Oracle Directory Management
offers the virtualization within Oracle Virtual Directory (OVD) OVD offers any LDAP clients the ability to query a single LDAP proxy to query many physical LDAP and non-LDAP identity repositories The technique of directory virtualization is being rapidly adopted over synchronization and meta-directory techniques, since it does not require information to be physically synchronized between servers and so results in a cheaper and faster approach to identity data integration Oracle Directory Management architecture is shown in Figure 8-7
NOTE
Chapter 9 discusses the Oracle Directory Management story in more
detail and shows how you can apply OID and OVD together and
independently to solve the basic challenges of creating a central
logical location for accessing identity information related to any user
in your enterprise.
Authentication Management
Authentication management is a category of solutions for identifying and verifying a user’s identity The tactics for the identification process can vary widely, but they always focus on proving that a user is who he or she claims to be Authentication management does not try to solve the issue of verifying authorizations, which is a separate category altogether The following types of solutions are included in this category:
Single sign-on (SSO) The ability to reuse an authenticated session in more than one
application
Enterprise single sign-on (ESSO) The ability to integrate an operating system-level
authentication or a thick desktop client’s authentication with that of your web SSO
■
■
Trang 2Chapter 8: Architecting Identity Management 375
Strong authentication and fraud prevention The ability to provide stronger levels of
authentication and risk analytics to prevent identity fraud
Federation The ability to integrate web authentication across partnered enterprises Database authentication Centralizes the authentications for database repositories to a
central user repository (for example, LDAP)
The Oracle Access Management suite offers all these solution both as independent solutions and as an integrated bundle Figure 8-8 shows the products that support each of these solutions Authentication management solutions are part of any access management architecture in which
a specific need exists to integrate authentication between one or more applications or technology platforms For each of these solutions, a server component manages and evaluates the authentication policies and an enforcement agent component is embedded within the application The specific server and agent architectures are described in the specific authentication solutions that follow
SSO Using Oracle Access Manager
Since OAM is mainly a web application authentication solution, its components are all designed
to protect applications in a typical web/HTTP environment As illustrated in Figure 8-9, Oracle Access Manager (OAM) has three key components:
Policy Manager The user interface for creating and managing SSO policies for the web
applications that need to be protected
Access Server The component that accepts requests from the enforcement points for
access control decisions (for example, password validations) and returns an allow/deny response to the enforcement point
Access Gate The enforcement component that is embedded in the application, typically
as a web server filter where the end user application is deployed
■
■
■
■
■
■
FIGURE 8-8 Authentication Management
Trang 3376 Part III: Identity Management
Keep in mind that the backend policy store (LDAP) can be a physical LDAP server (for example, OID or Active Directory) or a virtual LDAP directory (for example, Oracle Virtual Directory)
Enterprise SSO Solution Using Oracle eSSO
Enterprise SSO (eSSO), shown in Figure 8-10, is an integration solution between an operating system or a thick client platform, so its components are designed to sit between the desktop and the application The Oracle eSSO architecture has a component called the Logon Manager which sits
on the user’s desktop to integrate the OS authentication (such as Windows Domain Authentication) with other desktop client applications or web SSO components such as OAM Similar to OAM, it provides a management console for administrators to manage the eSSO policies
FIGURE 8-9 OAM Architecture
FIGURE 8-10 Oracle eSSO Architecture
Trang 4Chapter 8: Architecting Identity Management 377
Strong Authentication and Fraud Prevention
Using Oracle Adaptive Access Manager
To enforce fraud and risk management, an application must be able to detect irregular access behaviors in an application and prevent potential frauds or risky scenarios This kind of fraud detection is accomplished through intelligent metrics to score for a possible fraud candidate The Oracle Adaptive Access Manager (OAAM) provides this solution along with strong authentication capabilities
The combination of strong authentication and fraud/risk management makes OAAM a powerful tool for highly sensitive web applications that have a high degree of exposure to attacks For instance, OAAM is used by applications that sit on the public Internet and may be exposed to attacks from across the globe For example, an online banking application can use OAAM and its risk monitoring capabilities to detect irregular and user behaviors and possibly prevent fraudulent transactions from occurring Figure 8-11 illustrates the OAAM architecture
Federated Authentication Process Using Oracle Identity Federation
A federation solution focuses on authentication, and in many cases authorization, of information transactions across enterprise boundaries Figure 8-12 illustrates a sample federation request architecture in which a federation partner in domain A is trying to access information in a web application in domain B through a federated authentication process using Oracle Identity
Federation (OIF)
In this scenario, a requestor of information acts as the identity provider (IdP), and a server of information acts as the service provider (SP) The OIF IdP leverages federation standards, such as Security Assertion Markup Language (SAML) and Liberty, to propagate a user’s identity to the partner’s domain where the OIF SP accepts that request and evaluates the access request to the web application using a local set of federation and access policies If the requester is a valid user,
it allows the access to the federated web application and keeps the HTTP session alive as long as the federation token (for example, SAML token) is valid
FIGURE 8-11 OAAM architecture
Trang 5378 Part III: Identity Management
Centralized Database Authentication Using Oracle Enterprise User Security
Oracle Enterprise User Security (EUS) is a solution offered as part of the Oracle Database (since
version 9i) that uses an externalized LDAP server, such as Oracle Internet Directory, to externalize
database user authentications In addition to centralizing the authentication to the database, you can also centralize the authorizations for the authenticated sessions by mapping database roles and privileges to centralized LDAP groups Figure 8-13 shows typical solution when the architecture needs to support end user authentication into the database tier, perhaps for additional access control using database roles/privileges or performing end user auditing on the database objects (tables, views, and so on)
The Oracle products that enable this solution are the LDAP products (OID or OVD) and the EUS feature in the Oracle Database Server The choice of LDAP product is yours based on your requirements For instance, if you already have a physical LDAP server, you would simply layer the OVD product on top of the existing repository to make EUS work for your Oracle Database authentications
Authorization Management
Managing and enforcing proper authorizations in an application are two of the most difficult and growing challenges in identity management The topic of authorization management could fill an entire book for a comprehensive understanding of the solution In this section, we will discuss a summary of this class of solution and the basic overview of how Oracle is approaching this space
As shown in Figure 8-14, two kinds of authorization management solutions exist: web access management and entitlement management.
FIGURE 8-12 Federation architecture
Trang 6Chapter 8: Architecting Identity Management 379
Web access management is a solution to perform authorization checks on resources with a particular URI pattern (for example, xxxx/xxx/xx/pattern.*) This type of authorization is considered coarse-grained and works on web applications that are neatly partitioned using unique URLs, which are then mapped toward roles and privileges in the LDAP server This solution is useful for protecting application access at high levels, where the policies are adjacent to SSO policies The Oracle product that allows such coarse-grained authorizations is the same product that provides SSO functionality to web applications: Oracle Access Manager
FIGURE 8-13 Centralized database authentication
FIGURE 8-14 Oracle authorization management
Trang 7380 Part III: Identity Management
The second kind of authorization management, entitlement management, provides the ability
to authorize resources of any kind inside an application The objects can vary from HTML pages,
to Java objects, to Java 2 Platform Enterprise Edition (J2EE) beans, to data records, to user interfaces
in middleware applications This solution provides a much more flexible and sophisticated authorization framework for access control The Oracle Entitlement Server (OES) provides this kind of fine-grained entitlement (authorization) management solution
Oracle Entitlement Server Architecture
OES is a Java-based authorization framework that can integrate with Java and non-Java
applications The OES infrastructure comprises five essential components:
Policy store A database holding all the entitlement and authorization policies.
Policy administration point (PAP) The user interface where administrators can define
policies around authorizations to resources
Policy information point (PIP) A provider of policy data to the decision and
enforcement points
Policy decision point (PDP) A policy evaluation engine that decides whether to grant or
deny access to a user based on the information it is provided
Policy enforcement point (PEP) The location where the user is either granted or denied
access in the application
As the architecture shown in Figure 8-15 demonstrates, an application can integrate into the OES authorization decision-making framework in two ways First, an application can choose to make a direct call from application to the OES PDP for a grant/deny decision for a certain user trying to execute a certain action on a specific resource This approach requires an out-of-process call every time a protected resource is accessed and therefore can cause application performance degradation Alternatively, OES offers an embedded policy decision point option for certain types
of applications (for example, WebLogic servers, Oracle databases, Microsoft SharePoint servers, and so on) where components known as security modules can embed themselves as part of the application platform and make fast decisions without leaving the boundaries of the application’s policy enforcement point Installing a security module for your application relieves you of the responsibility of knowing how your application communicates with the OES components
OES is also changing the fundamental shape of access architectures by allowing for the separation of enforcement points from decision points This separation allows any future
application to reuse a huge repository of existing business and information privacy policies and therefore significantly lowers the time and cost of application development And maintenance is easier since making changes to policies no longer require application code changes
A Developer’s View of OES
Fine-grained access management is definitely on the rise in today’s application development space since building this kind of policy enforcement mechanisms into the foundation of any application makes it much more flexible and adaptive to changing enforcement policies For example, in today’s non-OES world, application developers are hard coding statements like this:
if (user.memberOf("Manager") {
changeSalary(" ");
■
■
■
■
■
Trang 8Chapter 8: Architecting Identity Management 381
This is a classic example of embedding an access control decision inside the application Instead, the method call could have been protected using the following code:
if (isAccessAllowed( user, policyId, action )
{
changeSalary(" ");
}
The benefit of the second approach is that tomorrow you could make changes to your policy
of granting Manager access to calling the changeSalary() method Perhaps you may want to add
the Executive role to be able to access that method as well Using an OES approach, you can offload the actual policies inside OES policies, which can be changed without affecting the application The only responsibility of the application will be to know the policy identifier to the appropriate policy it wants to enforce Also, as XACML is being adopted, you can start using declarative policy using the XACML constructs to make requests to the OES server
Role Mining and Management
Role mining is the ability to introspect and inventory all roles that exist in applications in the enterprise Once the roles have been mined, they can then be processed, analyzed, and consolidate into a single set of logical business roles that are mapped to enterprise access policies that define the access to different applications based on their business roles
FIGURE 8-15 OES component architecture
Trang 9382 Part III: Identity Management
Role management is another fast-growing space in identity management, since more enterprises are looking to automate identity provisioning policies–based functional business roles that represent their day-to-day responsibilities The Oracle role management solution is delivered by the Oracle Role Manager (ORM), which is an end-to-end mining, analytics, and management product for all roles across the enterprise ORM leverages a strong integration with the user provisioning solution (OIM) to execute the provisioning of accounts and roles in different systems based on policies defined within ORM The functional architecture for ORM is shown in Figure 8-16
As Figure 8-16 illustrates, ORM is the central rule and policy engine for deciding who belongs to what business roles, which then trigger access provisioning rules in OIM to execute the provisioning processes From a pure technical perspective, ORM is a type of rules engine that focuses and optimizes business rules around enterprise and technical roles It can store “static” roles that use a membership list approach to manage assignments to roles ORM can also use attributes and other identity information to dynamically assign business and technical roles to users The second
approach is more popular since it requires less administrative work to manage role assignments Role mining and management is a logical next step after implementing a user provisioning solution for an identity management architecture that is intended to automate processes and reduce risk of noncompliance with governance policies ORM does allow exceptions and
exception handling, which are mechanisms that override the central rules in case of temporary escalations or allowable one-off cases For example, an exception could be granting administrative privileges to an external contractor, hired to perform critical repair work on a server However, the number of exceptions should not grow so large that it starts looking like a new rule—in which case, you should probably create a new rule
In general, ORM projects are data intensive and should be properly planned up front to determine the scope of the implementation It is unwise to try to mine the entire enterprise for role information at the first phase of the implementation Instead, taking a more targeted approach, such as mining one application at a time, makes more sense and makes designing the business roles/hierarchies easier to handle It is reasonable to expect an imperfect role management design
FIGURE 8-16 ORM functional architecture
Trang 10Chapter 8: Architecting Identity Management 383
on the first pass of the project, since the ORM architecture factors ongoing changes to design without impacting the applications in a negative manner As you extend your role management solution to support new applications and new enterprise domains, you will inevitably and
continuously refine your roles and hierarchies in ORM
Summary
One of the main reasons this chapter was written was to emphasize the importance of
understanding identity management from the perspective of the problem As mentioned in the introduction, you may be tempted to jump right into building the solution without fully understanding the consequences of that solution path Unfortunately, when it comes to identity management problems, the challenge lies not in figuring out a solution to the problem but in deciding which solution to use As engineers, we can always fit and configure products and technologies to solve short-term and immediate problems However, this chapter encourages you to put on your architect hats before you start implementing specific solutions, such as User Provisioning or Directory Management, to ensure that your implementation design solves not just your immediate needs, but aligns with a longer term view of managing identities and enforcing application security