| Oracle® Access Manager Integration Guide 10g (10.1.4.0.1) Part Number B25347-01 |
|
|
View PDF |
| Oracle® Access Manager Integration Guide 10g (10.1.4.0.1) Part Number B25347-01 |
|
|
View PDF |
Oracle Access Manager 10g (10.1.4.0.1) provides an authorization plug-in that uses the Microsoft Windows Server 2003 Authorization Manager (AzMan) services to make authorization decisions for Access Server clients, including WebGates and callers of the Access Manager API.
This chapter explains how to configure a Oracle Access Manager policy domain for the 10g (10.1.4.0.1) AzMan Plug-in, and includes the following topics:
Authorization is the process that determines what access a user is permitted to have, and what a user is permitted to do, after they have been authenticated. Oracle Access Manager extends its access policies through authorization plug-ins.
An Oracle Access Manager authorization plug-in is a component that consists of a set of functions that reside in a dynamically-loaded native library to change or enhance Oracle Access Manager behavior. The AzMan Plug-in enables Access System authorization rules to use the facilities of the Microsoft Authorization Manager on Windows Server 2003.
When using the AzMan Plug-in:
WebGates can control access to Web content based on Authorization Manager policies.
Applications using the Access Manager API can use Authorization Manager policies through the ObUserSession isAuthorized() call.
WebGates and Access Manager API clients can be on any Oracle Access Manager-supported platform, which means that:
If your environment is primarily Microsoft, you can use the Authorization Manager to define policy for Windows-based applications and Oracle Access Manager can enforce those policies in the parts of the protected applications, such as ASP URLs, for instance.
In this case, you can define application roles in the Authorization Manager and Oracle Access Manager can use these roles when enforcing Web access control.
If your environment includes non-Windows applications, these applications can also use Authorization Manager policies.
Non-Windows applications can use the Access Manager SDK for the Authorization Plug-in API to get authorization decisions from the Authorization Manager through the AzMan Plug-in.
The AzMan Plug-in is executed by a Access Server during the evaluation of access policies. The Authorization Plug-in API enables the Access Server to use the plug-in to make outbound calls to external business logic. The external business logic determines whether a user is authorized to access a resource. The external business logic also determines whether to pass authorization actions during the evaluation of access policies.
The Authorization Plug-in API:
Provides the interface that the AzMan Plug-in implements and the Access Server calls
Provides the callback functions that the plug-in uses to retrieve additional data from the Access Server
Defines data structures that pass information between the AzMan Plug-in and the Access Server
For example, the ObUserSession.isAuthorized() method in the Access Manager SDK for the Authorization Plug-in API can evaluate AzMan policies for a user and, optionally, for a set of parameters.
For more information, see the following discussions:
Any references to specific versions and platforms in this chapter are for demonstration purposes.
To see the supported versions and platforms for this integration, refer to Metalink as follows.
To view information on Metalink
Go to the following URL:
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Application Server and click Submit.
The following figure introduces authorization with the AzMan Plug-in.
Process overview: WebGate operation with the AzMan Plug-in
The WebGate sends an ISAuthorized() request for the authenticated user and the URL to the Access Server.
The Access Server determines the URL is protected by a policy with an authorization rule that specifies an authorization scheme for the AzMan Plug-in.
If the authorization scheme requires request context values (configured as RA_user parameters in the authorization scheme) that are not available in the IsAuthorized request, the Access Server returns a NeedMoreData response to the WebGate.
When the WebGate receives the NeedMoreData status, the WebGate:
Gets the request context data indicated in the status
Resends the IsAuthorized request with the data
Continues processing with the beginning of step 2
If this is the first time the plug-in has been invoked, the Access Server loads the authz_azman library and executes the ObAzPluginInit() function in the library, which:
Creates the authz_azman_log.txt file in the install_dir/oblix/engine directory
Reads the authz_azman_msg.lst file in the default language directory of the installation
Checks that the Authorization API version of the Access Server is compatible with the plug-in
Initializes the COM interface
Creates a mutex to protect a global list of open application stores
The Access Server executes the ObAzPluginFn() function in the plug-in, which:
Gets its configuration parameters from the various plug-in data blocks
Searches the list of open application stores for a store matching the AzStore parameter
If no open store is found, the plug-in opens the store and puts it in the list
Creates an application object for the AzApplication parameter
Initializes a client context for the browser user
If an AzRole is specified, the plug-in sets the client context to the role
Converts the AzOperation parameter values to an array of IDs
If the AzRuleParameters is specified, the plug-in retrieves the corresponding parameter values from the plug-in data blocks and sets up arrays with the parameters and their values
Calls the AzMan AccessCheck() method for the client context, the scope (if specified), the operation ID array, and the rule parameter and value arrays (if present)
Interprets the result of the access check:
If the result is access allowed and AzContinueOnAllow=yes, the plug-in returns ObAzPluginStatusContinue, which instructs the Access Server to continue processing subsequent authorization rules (possibly invoking other plug-ins).
If the result is access allowed and AzContinueOnAllow=no, or is omitted, the plug-in returns ObAzPluginStatusAccessAllowed this causes the Access Server to immediately return allowed.
If the result is access denied, return ObAzPluginStatusAccessDenied, this causes the Access Server to immediately return denied.
The WebGate gets the IsAuthorized result from the Access Server and blocks or allows access to the requested URL.
Process overview: Access Manager API operation with the AzMan Plug-In
An application using the Access Manager API executes the ObUserSession IsAuthorized() method for an authenticated user, a resource, and optional set of parameters that may include Authorization Manager configuration parameters. The following process overview the operation of the Access Manager API and the Authorization Manager Plug-in.
The Access Manager API sends an IsAuthorized request with the authenticated user, resource, and parameters to the Access Server.
The Access Server determines the resource is protected by a policy with an authorization rule that specifies an authorization scheme for the AzMan plug-in.
If the authorization scheme requires request context values (configured as RA_ user parameters) that are not available in the IsAuthorized request, the Access Server returns a NeedMoreData status to the Access Manager API.
|
Note: This is not as likely to happen as with WebGate, since the application can include the required parameters in the isAuthorized() call. |
If Access Manager API gets the NeedMoreData status, it gets the request context data indicated in the status from the resource (for example, a query string) and resends the IsAuthorized request with the data.
Processing then continues with step 2 in "Process overview: WebGate operation with the AzMan Plug-in".
Steps 3 and 4 in this process are the same as in "Process overview: WebGate operation with the AzMan Plug-in". The parameters from the isAuthorized() call are in the request context data block.
The Access Manager API client in the application gets the IsAuthorized result from the Access Server and returns the result through the isAuthorized() call. The application then takes appropriate action.
For more information, see "Using the AzMan Plug-In with the Access Manager API".
The plug-in is included during Access Server installation in the following library:
AccessServer_install_dir\access\oblix\lib\authz_azman.dll
The AzMan Plug-in must be installed on each application server you want to protect. This enables you to complete authorization for resources protected by Oracle Access Manager using policies and roles defined outside the Access System policies, within the Authorization Manager in Active Directory, through the Authorization Plug-in API. For more information about the Authorization Plug-in API, see Oracle Access Manager Developer Guide.
|
Note: Oracle Access Manager does not provide or allow administration of Authorization Manager policies through the Policy Manager. |
Oracle Access Manager provides the custom AzMan Plug-in but not a custom authorization scheme, because external programs and calls to external business logic are unique from business to business.
A Master Access Administrator uses the Access System Console to define a custom authorization scheme that includes the full path to the shared library for the AzMan Plug-in.
A Delegated Access Administrator uses the Policy Manager to define a policy domain using the custom authorization scheme and plug-in parameters for the AzMan Plug-in as a basis for the authorization rules or action in a policy domain, and to protect resources.
For more information, see "Configuring the AzMan Plug-In".
This discussion explains authorization rules and schemes and AzMan Plug-in parameters for use with the Authorization Manager.
A Oracle Access Manager authorization rule allows or denies users the right to access the resources within the policy domain (or a subset of resources, if a policy applies). Authorization rules can be combined into expressions. For more information about chaining authorization rules, see the Oracle Access Manager Access Administration Guide.
|
Note: You define and enable authorization rules through the Policy Manager. When using the AzMan Plug-in, you need to create a custom authorization scheme that consists of a name, a description, a shared library path for the installed plug-in (without a platform-specific extension such as .dll), and a set of required and optional parameters. The purpose of the authorization scheme parameters is shown in Table 17-1. |
Table 17-1 Purpose of Authorization Scheme Parameters
| Scheme Parameters | Description |
|---|---|
|
User Parameters: User |
User profile attribute values passed into the plug-in in the RequesterInfo data structure. For more information, see. |
|
User Parameters: Request Context |
Request data (HTTP headers and cookies, Access Manager API parameters) passed into the plug-in in the RequestContext data structure.
|
|
Required Parameters |
Name-value pairs passed into the plug-in in the Context data structure. These must be specified in either the authorization scheme or the authorization rule. |
|
Optional Parameters |
Name-value pairs passed into the plug-in in the Context data structure. These may be specified in either the authorization scheme or the authorization rule or may be omitted. |
The AzMan Plug-in uses optional plug-in parameters to specify the input to the AccessCheck() method, IAzClientContext::AccessCheck(), discussed in "Using the AzMan Plug-In with the Access Manager API". If a plug-in parameter is not specified, the plug-in will check the User Parameters, Request Context data (see Table 17-1) for the omitted values. In this case, callers of the Access Manager API can supply these parameters in the ObResourceRequest constructor or the ObUserSession isAuthorized() call. AccessCheck() can return a value indicating that access is allowed or denied. The plug-in can take a different action based on the AzContinueOnAllow configuration parameter in Table 17-2. For details about the Access Manager API, see the Oracle Access Manager Developer Guide.
The plug-in parameters shown in Table 17-2 are specific to the AzMan Plug-in. You use them to specify input to the Authorization Manager.
Table 17-2 AzMan Plug-in Parameters
| Parameters | Description |
|---|---|
|
AzStore |
URL (msldap:// or msxml://) identifying the authorization store with the relevant policies. |
|
AzApplication |
Name of the application in the store containing the policies to be used. This must be specified. |
|
AzObject |
Name of the object to be identified in the AzMan audit log. If not specified, the Oracle Access Manager resource URL will be used. |
|
AzScope |
Name of the scope in the application containing the policies to be used. If not specified, no scope will be used and the default application policies will be applied. |
|
AzOperations |
Space-separated list of operation names to be used in the access check. Operation names with embedded spaces must be enclosed in quotation marks such as "an operation". If not specified, the Oracle Access Manager resource request operation name will be used. |
|
AzRuleParameters |
Space-separated list of names of parameters to be passed to AzMan authorization rules. Parameter names with embedded spaces must be enclosed in quotation marks such as "a parameter name". |
|
AzContinueOnAllow |
|
|
AzLogLevel |
|
The rule parameters (specified with AzRuleParameters in Table 17-2 are values from either the user's profile (User Parameters) or the values from the request (Request Context parameters). Rule parameters are passed to the Authorization Manager for possible use within authorization rules/scripts.
Table 17-3 shows the user parameters for IAzClientContext.
Table 17-3 User Parameters
| User Parameters | Description |
|---|---|
|
samacctuser |
Username to construct the IAzClientContext object. |
Table 17-4 shows the parameters for collecting authorization data from an external application that are configured as RA_user parameters in the authorization scheme.
Table 17-4 Request Context Parameters
| Request Context Parameters | Description |
|---|---|
|
AzRole |
Value is used as the role in the access check. |
|
rule parameters |
Post data, query data, and all other types of data appropriate for context-specific requests can be used in an authorization decision. For post data, postgate.dll must be installed. See the Oracle Access Manager Installation Guide for details. |
Table 17-5 summarizes what occurs when the Access Server evaluates a policy or policy domain that contains an authorization rule with a custom authorization scheme.
Table 17-5 Summary of Evaluation
| The Access Server | The Plug-In |
|---|---|
|
Executes the plug-in |
Extracts the parameter values from the passed data |
|
Collects relevant parameter values for the plug-in and the target user, resource, and request. |
Performs its designed tasks |
|
Adds these values to the appropriate data structures and executes the main plug-in function |
Returns a result with optional actions to the Access Server, which may include continue, allow, deny, or abort. |
|
The Access Server interprets the result and either continues processing authorization rules or stops and returns its result to the access client. |
For more information about authorization, see the Oracle Access Manager Access Administration Guide. For details about the Authorization API, see the Oracle Access Manager Developer Guide.
The Windows Server 2003 Authorization Manager is a role-based access control interface characterized by using collections of settings based on an object's role within an organization. The Authorization Manager provides a GUI tool to define access policy for applications and an API for applications to request access decisions using the policy. You can use role-based administration to manage users, computers, and other file-system and directory-service objects.
The Authorization Manager provides two modes of operation:
Developer Mode: Enables you to create, deploy, and maintain applications with unrestricted access to all Authorization Manager features.
You run Authorization Manager in developer mode only until the authorization store is created and configured. After you initially set up an application in developer mode, you can work in administrator mode.
Administrator Mode: The default mode, enables you to deploy and maintain applications and have access to all Authorization Manager features. However, you cannot create new applications or define operations.
Before you can use administrator mode, you must provide an application that supports roles, includes all of the necessary operation and task definitions, includes its own authorization store, and is ready for use in the Authorization Manager.
An authorization policy store contains information about the security policy of an application or group of applications. The information includes the applications, operations, tasks, users, and groups of users associated with the store.
The authorization policy store must be located on a trusted system to afford administrators on that system access to the store. The Authorization Manager supports storing authorization policy either in the Active Directory directory service or in an XML file:
Active Directory objects are identified by an LDAP DN in a URL.
For example:
msldap:// (for example, msldap://CN=MyAzStore, CN=Program Data, DC=authmanager, DC=com)
or
XML files are identified by a path in a URL.
For example:
msxml://C:\MyStore.xml
|
Note: Active Directory stores allow the delegation of administrative control. However, XML stores do not. |
By default, the group "Domain Admins" is listed within the Security tab when you create the Active Directory authorization store. To run the Authorization Manager policy through Oracle Access Manager, the Access Server user (for example, Administrator) should also be listed in the Users and Groups list within the Security tab. However, similar settings are not required for the XML store.
For more information about Authorization Stores, see your Microsoft documentation.
An application is a program that is designed to perform specific functions directly for the user or for another application.
An authorization store can contain policies for resources for multiple applications. Alternatively, an application's resources and associated policies may be subdivided into scopes. For example, if you do not want to apply Authorization Manager groups, role assignments, role definitions, or task definitions to an entire application, you can create them at the scope level.
A scope can be one of the following:
Folder
Active Directory container
File-masked collection of files, for example *.doc
URL
Any grouping of resources meaningful to the application
You can use scopes in Active Directory authorization stores to delegate control. For more information, see your Microsoft documentation.
In the Authorization Manager, an operation is a small computer-level action or method of an application. Operations are grouped together as tasks. An operation is defined by:
Name
Description
Operation number
|
Note: Operations can be defined at the application level but not the scope or store levels. |
A task is a high-level action that users of an application need to complete. Tasks are composed of the lower-level operations required to perform the task. Users of an application request permission to complete tasks. A task is defined by:
Name
Description
Set of other tasks and operations
Authorization rule (optional)
For more information, see your Microsoft documentation.
A role is a set of permissions that a user must have to perform the application's tasks. A role is defined by a:
Name
Description
Set of tasks, operations, and other roles that are granted by the role
Authorization rules that can test arbitrary conditions
Permissions are assigned or denied by the object's owner. The Authorization Manager is capable of implementing multiple configuration and permission changes at once and provides advantages over other management tools, such as the access control list (ACL) and Delegation of Control Wizard.
Authorization roles are based on a user's job function. You can use authorization roles to authorize access, delegate administrative privileges, or manage interaction with computer-based resources.
The Authorization Manager enables administrators to implement this role-based administration through applications. Applications using this role-based access are constructed to use logical roles that relate to the tasks performed by the application. The settings that authorize users for specific roles are made automatically through the use of scripts, called authorization rules, that enable you to control the mapping between access control and the structure of your organization.
For more information, see your Microsoft documentation.
A group defines a set of principals (users and computers) to which roles can be assigned. A group can be defined using:
Windows users and groups
LDAP queries
Other groups
A group specifies principals that are either:
Explicitly included (members)
Explicitly excluded (non-members)
|
Note: Circular group membership, for example, group A contains group B and group B contains group A, is detected and prohibited. |
Groups can be defined at the store, application, and scope levels. Assigning a group to a role grants the role's permissions to the users defined in the group. A role definition can also contain authorization rules that can test arbitrary conditions.
For more information, see your Microsoft documentation.
In the Authorization Manager, authorization rules are either VBScript or JScript scripts that can be used in role and task definitions. An authorization rule can determine whether the role or task is allowed. With authorization rules, you can base authorization decisions on any conditions that a script can test, including privileges and permissions, time of day, billable expense limits, account balances, and other criteria.
A rule associated with an object can regulate which users gain access and in what manner. Named parameter values can be passed from the application to the Authorization Manager for use within the scripts.
You can write your scripts in a text editor (for example, Notepad), in an integrated development environment like Visual Studio .NET, or in another application of your choice.
For more information, see your Microsoft documentation.
The Authorization Manager provides runtime auditing that records application-access checks using policies in an authorization store. The runtime audit log contains the relevant client contexts with the access checks. The Authorization Manager also provides authorization store-change auditing to record modifications to policies in authorization stores.
Runtime auditing can be applied at the authorization store and application levels for all stores, and at the scope level for Active Directory stores. Store-change auditing can be applied at the store, application, and scope levels for Active Directory stores, but only to the store level for XML stores.
For more information, see your Microsoft documentation.
An application program interface (API) includes the formal requests and means of communicating with other programs used by an application program. Windows Server 2003 provides Component Object Model Component Services (COM+) interfaces to manage and use Authorization Manager policies.
COM+ provides an infrastructure that enables clients and objects to work together. This binary standard enables interoperability between software components in a networked environment regardless of the language in which they were developed.
A COM client (software that uses and controls objects) does not know the internal workings of the objects (software that knows how to perform a specific task) the client is using. Clients and objects must communicate about and agree on the functionality that an object will supply to the client. This agreement is implemented in software by a COM interface.
For example, in the Authorization Manager API:
The state of a particular user (client) is represented by an IAzClientContext interface.
The object is created from one of the following:
IAzApplication::InitializeClientContextFromToken(): needs the user's token.
IAzApplication::InitializeClientContextFromName(): needs the user name and domain name.
IAzApplication::InitializeClientContextFromStringSid(): needs the string representation of the SID.
The AccessCheck method of the IAzClientContext interface method invokes the Authorization Manager to determine if the user represented by the IAzClientContext object is allowed to perform a specified application operation.
For more information, see your Microsoft documentation.
Topics in this section walk you through an application created with the Authorization Manager and the configuration details for the AzMan Plug-in.
In this example, a financial role is defined that includes the right to authorize expenditures and audit account transactions. The Authorization Manager enables you to implement this type of role-based administration through an application that you create.
You set up the authorization store, design your application using the Authorization Manager, define tasks, operations, roles, and make role assignments. Figure 17-1 shows the main Authorization Manager window and the hierarchy of the authorization store, MyAzStore.
In Figure 17-1 you can see the folders for Groups, Definitions, and Role Assignments for the application. Beneath the Definitions folder are the Role, Task, and Operation Definitions folders. In the right-hand panel, you can see the user assigned to the Expense Administrator role, user1k1.
The financial application, named "Expense", may have the operations shown in Table 17-6:
Table 17-6 Expense Application Operations
| Name |
|---|
|
RetrieveForm |
|
EnqueRequest |
|
DequeRequest |
|
UseFormControl |
|
MarkFormApproved |
|
SendApprovalNotify |
The Expense application may include a task, "Submit Expense", which consists of the operations in Table 17-6 and another task, Approve Expense, as shown in Table 17-7
Table 17-7 Expense Application Submit Expense Task Definition
| Name |
|---|
|
RetrieveForm |
|
EnqueRequest |
|
UseFormControl |
|
Approve Expense |
Figure 17-2 shows the Submit Expense task, as it appears in the Authorization Manager.
The Expense application includes a role, Expense Administrator, that consists of the tasks in Table 17-8. A user who is assigned the Expense Administrator role is authorized to perform the operations (See Table 17-7) to complete the Submit Expense task, among others identified as follows.
Table 17-8 Tasks for the Expense Administrator Role
| Tasks |
|---|
|
Submit Expense |
|
Approve Expense |
|
Nested role Expense Admin |
Figure 17-3 shows the Expense Administrator role-definition properties in the Authorization Manager. The Submit Expense task is identified; other tasks will be added.
The Expense application may include a group of "Approvers", to which the Expense Administrator role can be assigned. Members of the Approvers group are given permission to perform the tasks in Table 17-9.
Table 17-9 Approvers Group Tasks
| Tasks |
|---|
|
Submit Expense |
|
Approve Expense tasks |
|
Any tasks assigned to the nested Expense Admin role |
An authorization rule for the Expense application is a script that tests the user's expense amount (a parameter from the application) against the user's expense limit, which could either be another application parameter or could be determined by the script itself. The rule for this Expense application is shown in Figure 17-4.
Continuing with the Expense application example described and shown in "Example 1: An Expense Application", the following information explores the Oracle Access Manager policy domain for this application. Included is a custom authorization scheme for the AzMan Plug-in.
The Expense application has been implemented to use Web forms to input the expense data. An XML file is used, rather than storing Authorization Manager policies in the Active Directory. Both methods are valid.
Figure 17-5 shows a custom authorization scheme for the Expense application. Not all of the allowable AzMan Plug-in parameters are used. Your scheme may be different.
Figure 17-6 shows the Submit Expense policy domain, enabled in the Policy Manager.
Within the policy domain, resources have been added and protected, as shown in Figure 17-7 for /expense/submit.asp.
The policy domain authorization rule is as follows. Notice that it specifies the custom authorization scheme defined in the Access System Console earlier.
Name: Expense Authn
Description:
Authorization Scheme: Expense Authorization
There are no timing conditions for this specific authorization rule, though your rule may include these.
The plug-in parameters for this policy domain are shown next:
Profile attributes that are passed to the plug-In:
samaccountname
RA_expenseAmount
Optional parameters and values:
Name: AzLogLevel
Value: medium
Name: AzApplication
Value: Expense
Name: AzRule Parameters
Value: No Value Specified
Name: AzOperations
Value: No Value Specified
Name: AzStore
Value: msxml
The authorization rule uses the custom Expense Authorization scheme and passes the User Parameters and AzStore and AzApplication parameters as specified in the scheme. The rule adds an AzOperations value for the EnqueRequest operation and an AzRuleParameters value for the expenseAmount variable.
There are no actions associated with this particular rule; however, your application may have specific actions.
The default authentication rule for the policy domain is as follows. There are no authorization expressions or audit rules for this policy domain. Your environment may be different.
Name: Basic over LDAP
Description:
Authentication Scheme: Basic over LDAP
Next you see the access policy for /expense/submit.asp:
Name: AzMan Policy
Description:
Resource Type: http
Resource Operation(s) GET
POST
Resource ell
URL Pattern /expense/submit.asp
There are no authentication rules, authorization expressions, or audit rules defined for this policy.
The following scenario walks you through the process flow for the Oracle Access Manager and AzMan plug-in authorization process. This process flow remains the same no matter where the Authorization Manager resides. In the following scenario:
An Expense application was implemented to use Web forms to input expense data, as explained under "Example 1: An Expense Application".
An XML file is used for Authorization Manager policies, rather than storing these policies in the Active Directory. Both methods are valid, as described in "Authorization Stores".
The resource is protected by an Oracle Access Manager policy with an authorization rule based on a custom authorization scheme that passes parameters to the AzMan Plug-in, as described in "Using the AzMan Plug-In with the Access Manager API"
Process overview: AzMan authorization after a user is authenticated
The user (user1k1) submits an expense form to /expense/submit.asp using the Authorization Manager Submit Expense task.
The WebGate intercepts the POST request to /expense/submit.asp and sends an ISAuthorized() request for user1k1, and the URL, to the Access Server.
The Access Server passes the parameter to the AzMan.dll, which applies the Submit Expense Policy, determines the expenseAmount variable is needed, and returns a NeedMoreData response to the WebGate.
The WebGate retrieves expenseAmount=100 from the POST data and re-sends the ISAuthorized() request with the data to the Access Server.
The Access Server:
Applies the Submit Expense Policy again
Executes the AzMan Plug-in for the Expense Authorization Scheme
Passes the expenseAmount variable in the RequestContext data and the samaccountname for the user in the Requestor data
The AzMan Plug-in:
Constructs an IAzAuthorizationStore object, which in this case is for msxml://C:\MyAzStore.xml
Constructs an IAzApplication object for the Expense application
Constructs an IAzClientContext object for user1k1
Calls AccessCheck() for the client context with the following:
bstrObjectName = /expense/submit.asp
varScopeNames = {}
varOperations = {EnqueRequest}
varParameterNames = {expenseAmount}
varParameterValues = {100}
varInterfaceNames = {}
varInterfaceFlags = {}
varInterface = {}
The Authorization Manager runtime:
Determines that user1k1 is assigned to the Expense Administrator role
The Expense Administrator role can perform the Submit Expense and Approve Expense tasks and includes the EnqueRequest operation.
Determines that user1k1 is allowed to perform the EnqueRequest operation
The Authorization Manager executes the expense.vbs script with expenseAmount=100, the script tests expenseAmount < 500 and returns a BusinessRuleResult of TRUE.
The AzMan Plug-in receives the allowed result and returns Allowed.
The Access Server returns an allowed response to WebGate.
WebGate allows the POST request processing to proceed.
The following information is provided to guide you during the configuration needed to use the AzMan Plug-in. Some information is tailored for the Expense example discussed earlier. Your specifications may be different. Sample screens are presented in "Example 2: Oracle Access Manager Configuration".
Task overview: Configuring the AzMan Plug-in
Prepare your environment, as described in "Preparing Your Environment".
Configure authorization schemes, as described in "Creating an Authorization Scheme for the AzMan Plug-In".
Protect resources, as described in "Protecting Resources".
Configure authorization rules and policies, as described in "Defining Authorization Rules and Policies".
Use the AzMan plug-in, as described in "Using the AzMan Plug-In with the Access Manager API".
For a process overview, see "Using the AzMan Plug-In with the Access Manager API".
The following procedures must be completed before you begin.
Task overview: Preparing your environment
Install and set up Windows Server 2003 on the machine that will host the Access Server, as described in your Microsoft documentation.
Install and set up Oracle Access Manager, as described in the Oracle Access Manager Installation Guide.
The AzMan Plug-in is included with the Access Server, as discussed under "Oracle Access Manager Components and Requirements".
Set up the AzMan authorization store, azman.msc, as described in your Microsoft documentation.
|
Note: By default, the group "Domain Admins" is listed within the Security tab when you create the Active Directory authorization store. The Access Server user (for example, Administrator) should also be listed in the Users and Groups list within the Security tab. Similar settings are not required for the XML store. |
Design your application using the Authorization Manager to specify operation, task, and role definitions and role assignments, as described in your Microsoft documentation.
The following steps presume that you have already defined an authentication scheme for this policy domain. The authorization scheme that you create can be included with any policy domain or policy and must include an authorization rule.
When you create a custom authorization scheme be sure to enter the full path to the shared authz_azman library (without the extension). You must also specify the user profile attribute values to be passed to the plug-in with the RequesterInfo data structure (the username is used to construct the IAzClientContext object). Also, specify the AzMan Plug-in parameters needed for your own application. For more information about policy domains and authorization rules, see the Oracle Access Manager Access Administration Guide.
To create a custom authorization scheme
Navigate to the Access System Console:
http://hostname:port/access/oblix
Within the Access System Console, click Access System Configuration, Authorization Management.
Click the Add button to begin a custom authorization scheme.
Enter the information for your custom authorization scheme.
For example:
Name: Name of this custom authorization scheme
Description: Optional description.
Shared Library: Full path to the authz_azman library (without the extension) c:\coreid\access\oblix\lib\authz_azman
User Parameter: samaccountname RA_expenseAmount (The RA_expenseAmount is a reverse action user parameter that is needed only if the authorization rule expects parameters).
Optional Parameters:
zAzApplication Expense AzRuleParameters AzOperations AzStore msxml://C:\MyAzStore.xml
Save the scheme, as usual.
You need to create a policy domain and add resources to protect. For general information about policy domains, see the Oracle Access Manager Access Administration Guide.
To create a policy domain and add a resource
Click the Policy Manager link or navigate to the Access System administration URL and select the Policy Manager application:
http://hostname:port/access/oblix
Click Create Policy Domain in the left navigation pane and create a policy domain.
For example:
Name: Submit Expense Description: Optional
|
Note: Do not enable the policy domain until you have finished all specifications for it, as described next. |
Click Save.
Add a resource to protect with this policy domain: Policy Manager, My Policy Domains, link, Resources, Add
For example:
Resource Type: http URL Prefix: /expense Description: Optional
Click Save.
You need to add the custom authorization scheme you created earlier to an authorization rule. The following steps presume that you have already defined your authentication rule for this policy domain.
To add the authorization scheme to the authorization rule
Navigate to Authorization Rules page: Policy Manager, My Policy Domains, link, Authorization Rules.
Click the Add button to display the Create Authorization Expression page.
Select Custom Authorization Scheme from the list, then click Add.
For example:
Authorization Scheme: Custom Authorization Scheme
A new page appears where you enter details for this rule.
Enter the details for this authorization rule, and confirm that the authorization scheme you created earlier is selected in the Authorization Scheme list.
For example:
Name: Expense Authn Description: Optional Authorization Scheme: Expense Authorization
Save the rule, as usual.
Return and click Plug-in Parameters; confirm the profile attributes to be passed to the plug-in from the authorization scheme match those you specified in your custom authorization scheme.
For example: Profile Attributes Passed to Plug-In: samaccountname RA_expenseAmount
| Optional Parameters: | Name | Value |
|---|---|---|
| AzLogLevel | medium | |
| AzApplication | Expense | |
| AzRuleParameters | No Value | |
| AzOperations | No Value | |
| AzStore | msxml |
Modify and save, if needed.
Add timing considerations and actions, as needed for your application.
To add default rules and the authentication rule
Click the Default Rules link.
Click the Add button on the Default Rules page to add an authentication rule, which includes an authentication scheme.
Enter the details and save as usual.
For example:
Name: AzMan Basic Over LDAP Description: Optional Authentication Scheme: Basic Over LDAP
Click the Policies link to add an access policy for the application.
Click the Add button on the Policies page.
Fill in the requested information for your application and policy domain.
For example:
Name: SubExp Access Policy Description: Refines control of the resource Resource type: http Resource Operations: GET POST Resource: All URL Prefix: /expense URL Pattern: /expense/submit.asp
This policy contains no query string or query string variables.
Save the policy, as usual.
Delegating Administration is done as usual. There are no special requirements for the application in this example. For more information, see the Oracle Access Manager Identity and Common Administration Guide.
Click the General tab and enable the policy domain, as usual.
You request the resource as usual and Oracle Access Manager will complete the authorization process as described under "Example 3: Authorization Process Flow".
The following example is provided as a guide if you want to use the Access Manager API with the AzMan Plug-in. For general information about the Access Manager API, see theOracle Access Manager Developer Guide.
// Set up the Expense resource.
ObResourceRequest rr = new ObRequestRequest("http", "/expense/submit.asp", "POST");
// Authenticate DOMAIM\jsmith.
Hashtable creds = new Hashtable(); creds.put("username", "user1k1"); creds.put("password", "oblix"); ObUserSession user = new ObUserSession(rr, creds);
// Check if administrator is authorized to submit an expense form with expenseAmount=100.
// This uses the AzStore and AzApplication parameters defined by the Expense
// Authorization scheme and the AzOperations and AzRuleParameter expenseAmount
// defined by the Submit Expense Authorization Rule. //
// Equivalent access_test_cplus command:
// user1k1 oblix GET http://dotnet/expense/submit.asp dotnet expenseAmount=100
Hashtable parameters = new Hashtable(); parameters.put("expenseAmount", "100"); if (user.isAuthorized(rr, parameters)) {
// authorized
}
else {
// not authorized.
}
// Check if administrator is authorized to perform the UseFormControl operation in
// the Expense application. This uses the AzStore and AzApplication parameters
// defined by the Expense Authorization scheme but overrides the AzOperations
// parameter in the Submit Expense Authorization Rule.
//
// Equivalent access_test_cplus command:
// user1k1 oblix GET http://dotnet/expense/submit.asp dotnet
// expenseAmount=100&AzOperations=UseFormControl
parameters.put("AzOperations", "UseFormControl"); if (user.isAuthorized(rr, parameters)) {
// authorized
}
else {
// not authorized.
}
// Check if the Expense Administrator role is authorized to perform the
// UseFormControl operation in the Expense application. Note that user1k1 must
// have this role.
//
// Equivalent access_test_cplus command:
// user1k1 oblix GET http://dotnet/expense/submit.asp dotnet
// expenseAmount=100&AzRole=Expense+Administrator&AzOperations=UseFormControl
//
// Note that access_test_cplus does not actually convert + to blank, but it should.
parameters.put("AzRole", "Expense Administrator");
if (user.isAuthorized(rr, parameters)) {
// authorized
}
else {
// not authorized.
}
An "Insufficient access right" error may appear in the log file when the Access Server user (for example, Administrator) does not appear in the Security tab of the Active Directory authorization store.
By default, the group "Domain Admins" is listed within the Security tab when you create the Active Directory authorization store. To run the Authorization Manager policy through Oracle Access Manager, the Access Server user (for example, Administrator) should also be listed in the Users and Groups list in within the Security tab. However, similar settings are not required for the XML store.
