Policy Configuration - Shared Components and Application Domains

5

Policy Configuration: Shared Components
and Application Domains

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Objectives
After completing this lesson, you should be able to:
• Manage shared components
– Resource types
– Host identifiers
– Authentication schemes

•

5-2

Configure application domains

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Road Map
•
•
•
•
•
•

5-3

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

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


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
resources.
Shared Components include:
– Resource types

– Host identifiers
– Authentication schemes

•

Resource types include:
– Kinds of resources include: HTTP or HTTPS (default) and
custom.

5-4

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


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

•

•
•

5-5

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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Road Map
•
•
•
•
•
•

5-8

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

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Access Control
•
•
•

Authenticates and authorizes access to protected and
public resources
Is a centralized credential collector
Authentication
–
–
–
–
–

•

Anonymous
Username/password (Form, Basic)
WNA
X.509
Authentication levels and step up

Authorization
– User/group
– IP address
– Time-based

5-9

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Access Control
1. Unauthenticated Access

7. Application Access

2. Redirect to Central Login Page

OAM Agent

Application

3. Submit Credentials

5. Validate Session &
Authorize

End User
Credential
Collector

4. Authentication

AuthN
Engine

6. Authorize

AuthZ
Engine

Oracle Access Manager 11g
Oracle WebLogic Server

5 - 10

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Authentication
•
•
•

•
•
•

5 - 11

The authentication engine is driven by authentication

schemes.
Authentication policies determine the applicable
authentication scheme.
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.

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Authorization
•

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>)
—
—

5 - 12

IF ip=x.x.x.x & time=Sunday
RESPOND WITH <header(name=val), cookie(name=val)>

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Road Map
•
•
•
•
•
•

5 - 13

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

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


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

5 - 14

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Authentication Module Features
•

LDAP Module
– 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)

5 - 17

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Authentication Module Features
•

X509 Module
–
–
–
–

•

Asserts identity by using X.509 client certificates
Credentials required: Client certificate
Verifies certificate by using Java Security API
Supports a configured OCSP responder

Anonymous Module
– Creation of a subject or session without user identity
validation
– Credentials required: none
– Anonymous username is configurable

5 - 18

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Step-Up Authentication Feature
•
•
•

•

•
•

5 - 19

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.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Shared Components: Authentication Schemes
•
•
•

Resources within an application domain are protected by
AuthN policies.
Each AuthN policy is defined by one authentication
scheme.
The authentication scheme defines:
– Challenge mechanism
—

—

Challenge method: Form, Basic (LDAP), X.509 (certificate),
WNA (Windows native authentication), none
Challenge redirect URL

– Authentication levels: 1, 2, and so on.
– Authentication module: X.509, LDAP, Kerberos

•
•
5 - 20

An authentication module is the smallest executable unit of
an authentication scheme.
Only one authentication module must be assigned to an
authentication scheme.
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


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

5 - 22

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Multi-Level Authentication

5 - 24

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

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 reauthenticate.

•

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.

5 - 25

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Road Map
•
•

•
•
•
•

5 - 27

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

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


Policy Object Comparison: OSSO 10g

5 - 28

OSSO 10g

OAM 11g

Partner Application URL (in modosso.conf)

Resource

Authentication plug-in

Authentication module

Authentication level

Authentication scheme level

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


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.

5 - 29

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


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.
5 - 30

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


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.

5 - 31

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.


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.

5 - 32

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.