Policy Configuration - Shared Components and Application Domains

Road Map• Resource types and host identifiers • Explaining access control: AuthN and AuthZ • AuthN modules and AuthN schemes • Understanding policy objects and policy model • Managing an

Policy Configuration: Shared Components

and Application Domains

After completing this lesson, you should be able to:

• Manage shared components

Road Map

• Resource types and host identifiers

• Explaining access control: AuthN and AuthZ

• AuthN modules and AuthN schemes

• Understanding policy objects and policy model

• Managing an application domain: Resources,

AuthN and AuthZ policies

• Pictorial representation: Application domain and policy objects

Shared Components: Resource Types

• Shared components, along with application domains,

comprise policy configuration within OAM

• You can find them in WLS admin console > Policy

Configuration > Shared Components

• Shared components are those elements that can be used

across application domains to protect one or more

• Resource types include:

– Kinds of resources include: HTTP or HTTPS (default) and

custom.

Shared Components: Host Identifier

• Host identifiers specify where the agents reside

• A host can be known by multiple names

– List of all addressing methods for the host

• OAM agents protect all requests that match

– The host identifier used in the policy (application domain)

– All the addressing methods that you configured for that host

• A host identifier is automatically created when you register

an agent by using the OAM admin console or remote

registration tool

– Administrators can also manually add a host identifier.

• Administrators can apply security policies to resources based on

host identifiers.

• Each resource and host identifier combination must be unique

across all application domains.

Road Map

• Resource types and host identifiers

• Explaining access control: AuthN and AuthZ

• AuthN modules and AuthN schemes

• Understanding policy objects and policy model

• Managing an application domain: Resources,

AuthN and AuthZ policies

• Pictorial representation: Application domain and policy objects

Access Control

End User

4 Authentication 6 Authorize

Oracle Access Manager 11g

Oracle WebLogic Server

3 Submit Credentials

1 Unauthenticated Access 7 Application Access

5 Validate Session &

Authorize

OAM Agent

Application

Credential Collector

AuthN Engine

2 Redirect to Central Login Page

AuthZ Engine

• Each authentication scheme consists of a CHALLENGE

metadata and reference to an instance of an authentication module

• Centralized credential collector

• Supported authentication module types are LDAP, X.509

and Kerberos

• Authentication or user mapping is performed against a

primary identity provider

• Authorization is performed through an embedded OES

engine with OAM extensions:

– OAM custom resource matching

– OAM constraint evaluation (IP and time)

• Policies are persisted to the database (Oracle DB)

• Support for user/group, IP address, and time constraints:

– ALLOW jdoe for RESOURCE(<hostid:uri>)

— IF ip=x.x.x.x & time=Sunday

— RESPOND WITH <header(name=val), cookie(name=val)>

– DENY jsmith for RESOURCE(<hostid:uri>)

— IF ip=x.x.x.x & time=Sunday

— RESPOND WITH <header(name=val), cookie(name=val)>

Road Map

• Resource types and host identifiers

• Explaining access control: AuthN and AuthZ

• AuthN modules and AuthN schemes

• Understanding policy objects and policy model

• Managing an application domain: Resources,

AuthN and AuthZ policies

• Pictorial representation: Application domain and policy objects

Authentication Module

• AuthN modules are plug-ins used in AuthN schemes.

• Three types of AuthN modules are supported:

– LDAP

– Kerberos

– X.509

• You can create several different AuthN modules based on one of

the three AuthN module types to use in AuthN schemes.

• For LDAP AuthN module, specify:

– Name and user identity store

• For X.509 AuthN module, specify:

– Name, matched LDAP attribute, X509 cert attribute, Cert validation enabled, OCSP enabled, OCSP server alias, OCSP responder URL, OCSP responder timeout

• For Kerberos AuhN module, specify:

– Name, keytab file, principal, KRB CONFIG file

Authentication Module Features

– Validates identity against the primary ID store [LDAP]

– Credentials required: username and password

– Supports only username verification

(no password required) for identity assertion

– Performs back-end operation for basic and form credential

collection mechanisms

• Kerberos Module

– Asserts identity by using an SPNEGO token and GSS APIs

– Credentials required: SPNEGO token

– Supported with fallback mechanism (BASIC)

Authentication Module Features

– Asserts identity by using X.509 client certificates

– Credentials required: Client certificate

– Verifies certificate by using Java Security API

– Supports a configured OCSP responder

– Creation of a subject or session without user identity validation

– Credentials required: none

– Anonymous username is configurable

Step-Up Authentication Feature

• The components involved are the credential collector, SSO, and

authentication engine.

• A user authenticates the OAM-protected resource via OSSO or

an OAM agent at level X.

• After authentication, the user accesses a resource that is

protected with an authentication scheme having Level Y, where Y>X

• Since the access request is evaluated at OAM

WebGate/mod_osso, the agent detects the insufficient level to access the resource

• The agent redirects the user to the OAM server to authenticate

again.

• The OAM server challenges the user according to the level or

type of authentication scheme configured in the policy for the resource.

Shared Components: Authentication Schemes

• Resources within an application domain are protected by

— Challenge redirect URL

– Authentication levels: 1, 2, and so on.

– Authentication module: X.509, LDAP, Kerberos

• An authentication module is the smallest executable unit of

an authentication scheme

• Only one authentication module must be assigned to an

authentication scheme

Shared Components: Authentication Schemes

• Challenge Methods:

– Form – Custom HTML login page

– Basic – Default Web server challenge using a pop-up box for

username and password fields

– WNA – Uses Windows Native Authentication with AD

– X509 – Requests X509 certificate from the client browser for

two-way SSL

– None

Multi-Level Authentication

Multi-Level Authentication

• Different resources of the same application can be

protected with different authentication levels

• Registered agents detect the different levels :

– mod_osso detects the authentication level from dynamic directives

– OAM agents receive an Insufficient Level error message from the OAM server (in case of step-up AuthN).

– Both agent types redirect the user to the OAM server to

re-authenticate.

• All the resources protected by mod_osso on a host are

protected at the same level

– For mod_osso, multi-level authentication applies to

resources across hosts.

Road Map

• Resource types and host identifiers

• Explaining access control: AuthN and AuthZ

• AuthN modules and AuthN schemes

• Understanding policy objects and policy model

• Managing an application domain: Resources,

AuthN and AuthZ policies

• Pictorial representation: Application domain and policy objects

Policy Object Comparison: OSSO 10g

Partner Application URL (in

mod-osso.conf)

Resource Authentication plug-in Authentication module

Authentication level Authentication scheme level

Policy Model: Key Differences Between OAM 11g

and OSSO 10g

Flexible authentication:

• In OSSO, there is a one-to-one mapping from AuthN level

to plug-in; in OAM 11g it is many-to-many.

• In OAM 11g, there is no default authentication level or

plug-in used for unspecified partner URLs or resources; AuthN policies need to be explicitly specified

Policy Model: Key Differences Between OAM 11g

and OAM 10g

Resource simplification:

• No more URL prefixes Resources are defined as complete

URLs (host id + relative pattern), and solely used to

determine the policy applicable to a request

• There is currently limited wildcarding support (“*” and “…”,

behave identically to 10g).

Application domains:

• They are simple organizational containers with no logic

associated with them at evaluation time

Responses:

• They are expression-based and much more powerful.

• They can provide user, request, and session information.

Policy Model: Key Differences Between OAM 11g

and OAM 10g

Policy simplification:

• Closed world: Access is denied to resources, unless a

policy specifically allowing that (regardless of whether

AuthN is required or not) is created

• Policy evaluation no longer returns INCONCLUSIVE

• No more per-domain “default policies.” A requested

resource matches either a single policy in the system, or none

• Redirection URLs are now a policy element, and not a

response

• Audit policies have been replaced by Common Audit

Framework

Other Policy Features in OAM 11g

Authoring/Provisioning:

• Policy objects for intra-suite and applications integration

are provided out-of-the-box (loaded to the DB at the first admin server startup)

• Policy objects for applications (with simple needs) are

automatically added as part of the remote registration process

Test to Production Support:

• Incremental policy sets are exported to file, and imported

into another instance

Road Map

• Resource types and host identifiers

• Explaining access control: AuthN and AuthZ

• AuthN modules and AuthN schemes

• Understanding policy objects and policy model

• Managing application domain: Resources,

AuthN and AuthZ policies

• Pictorial representation: Application domain and policy objects

Application Domain: AuthN Policies

• The OAM 11g policy model provides both AuthN and

AuthZ services within the context of an application domain

• Application domains contain:

– Resources

– Associated authentication and authorization policies

• They can be created manually or implicitly when you

register an agent with OAM

• Each authentication policy is a combination of:

– A single authentication scheme

– Success and Failure URLs to direct events following an

Application Domain: AuthZ Policies

• OAM 11g provides coarse-level authorization using AuthZ

policies:

– For fine-grained AuthZ, use OES MicroSM.

• Each authorization policy is a combination of:

– One or more resources to which the authorization policy

applies

– Success and Failure URLs to direct events following an

authorization attempt

– Specific conditions or constraints whose outcomes

determine whether access to the requested resource should

be granted

– One or more responses performed by the Web agent after

the authorization process

• A resource represents the content being protected.

• A resource is invoked by using a particular protocol based on the

associated resource type (HTTP, HTTPS and so on).

• Resource definitions are contained within an application domain.

• Each resource can be protected by only a single authentication

and authorization policy within an application domain.

• The host identifier defines the resource’s location on a particular

server.

• The URL value of a resource must begin with and must match a

resource value for the chosen host identifier.

• The asterisk (*) matches zero or more characters.

• Ellipses (…) represent a sequence of zero or more intermediate

levels.

Key URL Patterns

• Policy model does not support a resource prefix.

• There is no policy inheritance.

Authentication Policies

• A single policy can be defined to protect one or more

resources in the application domain

• Each resource can be protected by only one authentication

• Authentication response data elements are returned to the

client (typically a Web agent) after authentication

– Type: Header or session or cookie

– Value: Hardcoded or dynamic

Authorization Policies

• Each resource assigned to an application domain can be

protected by only one authorization policy

• Authorization policy includes:

– Unique name

– Success and Failure URLs

– Use implied constraints

– Resources

– Conditions/constraints

– HTTP responses

• After a policy has been evaluated, two standard actions

are performed:

– The result is returned.

– The user is shown something based on that result, either the

URL requested (on success), or redirected to a generic error page (on failure) Either or both can be overridden on a per- policy basis.

• Responses declare optional actions to be taken

additionally (hence their OAM 10g name “Actions”).

• In OAM 11g, responses are much more declarative and

powerful, and are able to support functionality that used to

require custom AuthZ plug-ins in OAM 10g.

What Are Responses?

• A response consist of two inputs, a type and an expression; and

a single output, the value.

• You can configure actions or responses on the basis of

authentication and authorization events.

• The responses can be the following:

– Redirecting to another URL upon success or failure

– Returning HTTP header variables or cookies or storing information

in a session object

• Enter the Name, Type and Value fields on the Response tab.

• Enter the Success and Failure URL fields on the AuthN/AuthZ

page.

• The response type denotes the form of action to be taken with

the value string They are:

– Request, Session, and User

• SSO integration with applications, particularly legacy or

third-party ones, which have ways to bypass, but not

entirely disable, built-in AuthN

• In OAM10g, the passing of data to (and between)

applications, by hitting URLs in a specific, but fragile,

sequence

• New in OAM 11g, the ability to insert information into a

session and pull it back out at any later point This is more robust and flexible than the above

How Are Responses Used?

Authentication and Authorization Responses

• Return session or user data are obtained as a result of

authentication or authorization

• Responses are sent to the agent that helps manifest them

as either HTTP headers or cookies

• Session attributes are set via responses.

• Expressions are defined as their own, though very small,

domain-specific language (DSL)

• Responses are prefixed with HTTP_<NAME>

• This language consists of two main constructs, and some

syntactic sugar:

– Literal strings: “This is a valid expression”

– Variable references: These are declared using a prefix $, and are always scoped to a namespace

“$namespace.var_name”

— Note: certain vars include an attribute: “$ns.name.attribute”

– The ability to combine literals and variables arbitrarily by

using braces: “Value:${ns1.var1}/${ns2.var2}”

– The ability to escape things which need to pass through

without processing applied, by using \ “\$1000”

Response Expressions

Response Examples

• The response expression declares how the value should

be built when the expression is processed.

• Simple response: $namespace1.var1

• Authentication success responses are replayed with

authorization responses on the first applicable

authorization request

• In OAM 11g, responses are set on request success only,

whereas in OAM10g, it was possible to do so in case of

failure as well

• Authorization: After the policy is evaluated to ALLOWED,

responses are processed and applied (session attributes set, headers and cookies returned to WG) at the end of the request

• Authentication: OAM 11g emulates the OAM 10g

ObTriggerAuthentication mechanism as follows:

– AuthN responses are saved within the session on creation.

– On the first AuthZ request for the exact URL which triggered

the entire OAM flow, these responses are extracted (and removed) from the session, processed, and returned as normal.

– Any AuthZ response for the same request with conflicting

names override the AuthN response.

Response Flows