PK fp@oa,mimetypeapplication/epub+zipPKfp@iTunesMetadata.plist[ artistName Oracle Corporation book-info cover-image-hash 907944965 cover-image-path OEBPS/dcommon/oracle-logo.jpg package-file-hash 254559166 publisher-unique-id E10043-10 unique-id 585860536 genre Oracle Documentation itemName Oracle® Fusion Middleware Application Security Guide, 11g Release 1 (11.1.1) releaseDate 2011-11-03T16:22:58Z year 2011 PKǤO`[PKfp@META-INF/container.xml PKYuPKfp@OEBPS/part_osso.htm/ Single Sign-On Configuration

Part IV

Single Sign-On Configuration

This part describes how to configure single sign-on in Oracle Fusion Middleware in the following chapters:

PKd4/PKfp@OEBPS/index.htm Index

Index

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  R  S  T  U  V  W  X 

A

AbstractTypedPermission, 20.3.4
access control list, 8.5.1.1
Access Server
cache, 17.6.1
AccessGate
configureAccessGate tool, 17.4.2.1, 17.8.6
ACL, 8.5.1.1
add.application.roles, 21.1
add.authenticated.role, 21.1
addBootStrapCredential, 10.5.6
addPrincipalsToAppRole, 20.2.3
administration tools, 5.1
administrative tasks, 5.4
administrators group, 2.5
Anonymous and Authenticated Roles Properties, F.2.5
anonymous role, 2.4, 2.4.1, 5.2
anonymous role and authentication, 2.4.1
anonymous SSL, 8.5.1
anonymous user, 2.1, 2.4, 2.4.1
anonymous user and role, 21.1
app.context, 8.7.3.3
Application Name or Stripe, 21.1
application policy, 2.1
application role, 2.1, 21.1
application role hierarchy, 9.3.4
application stripe, 21.1, 21.1
application.name, 21.1, 21.1
ApplicationRole class, 2.2.1
application-specific policies and roles, 3.2
audit data
bus-stop files, 13.2.5
file management, C.6
migrating, 13.5.5
reports, 14.1
audit data store
backup and recovery, 13.5.6.2
configuring for Java components, 13.2.3.2
configuring for system components, 13.2.4
data purge, 13.5.6.3
de-configuring, 13.2.4.1
partitioning, 13.5.6.1
schema, 13.5.1
tiered archival, 13.5.6.4
Audit Flow, 12.3.1
audit logs, 13.4
audit policies migration, 6.5.3
audit policy, 13.3
event filters, 12.3.2
audit report
example of, 14.4
audit reports
attributes, 14.5.2
by component, C.2.2
custom, 14.6.2
list of standard, 14.5.1
types of, 14.2
viewing, 14.3
Audit Schema, C.3
audit service, 28
audit-aware components, C.1.1
auditing
event attributes, C.1.3
events, C.1.2
filter expression syntax, C.5
for Oracle Fusion Middleware components, 13.3
in Oracle Fusion Middleware, 12
Java components, C.1.1
manual policy management, 13.3.4
manually configure for Java components, 13.3.4.2
manually configure for system components, 13.3.4.4
Oracle Directory Integration Platform, C.1.2.1
Oracle HTTP Server, C.1.2.3
Oracle Identity Federation, C.1.2.5
Oracle Internet Directory, C.1.2.4
Oracle Platform Security Services, C.1.2.2
Oracle Virtual Directory, C.1.2.6
Oracle Web Cache, C.1.2.11
Oracle Web Services Manager, C.1.2.12
overview, 12.2
OWSM-Agent, C.1.2.7
OWSM-PM-EJB, C.1.2.8
policy management with Fusion Middleware Control, 13.3.1, 13.3.2
policy management with WLST, 13.3.3
record storage, 12.3.4
report filters, 14.1.5
report setup for Oracle Business Intelligence Publisher, 14.1.3
report templates, 14.1.4
Reports Server, C.1.2.9
system components, C.1.1
WLST commands, C.4
WS-Policy Attachment, C.1.2.10
Authenticated Role, 21.1
authenticated role, 2.3, 5.2, 21.1
authenticated user, 2.1
Authentication providers, 18.1.2.4
DefaultAuthenticator, 16.2.4.2.4, 16.2.5.1, 16.2.6.1, 17.4.3.3, 17.5.3, 17.6.2, 18.1.2.4
LDAP Authentication, 16.2.4.2.1, 17.4.3.1
OAM, 15.2, 15.2
OAM Authenticator, 16.2.5.1, 17.5.3
OAM Identity Asserter, 16.2.4.2.4, 16.2.6.1, 17.4.3.3, 17.6.2
OID Authenticator, 16.2.4.2.4, 16.2.6.1, 17.4.3.3, 17.6.2, 18.1.1.2, 18.1.2.4
OSSO Identity Asserter, 18.1.2.4
WebLogic, 15.1
authenticator flags, 3.1.2.2
Authenticator for OAM, 15.2
Authorization failure, 20.3.3
authorization failure, 9.1
Auto login, 8.7.3.1
autologin.url, 8.7.3.3

B

backup, 5.2
basic security tasks, 5.2
bootstrap credentials, 6.3.1, 23.1.2
Bulk authorization, 23.2
bulkload, 6.5.2.3

C

cache
Access Server, 17.6.1
refresh frequency, 9.4.1
cache refresh, 9.4
caching, 9.4, 9.4
Cascading deletions, 23.2
characters allowed in policies, L.16.2
characters in security artifacts, 9.1
checkBulkAuthorization, 20.3.3.3
checkPermission, 20.3.3, 20.3.3.1, 20.3.3.1, L.1.1.3.1
choosing
the right SSO solution, 15
class path, 1.5.3, 3.2, 8, 9.2.1, 9.3.4, 21.4.6, E.2.3
class permission, 21.4.6
CredentialAccessPermission, 21.4.6.2
JpsPermission, 21.4.6.3
PolicyStoreAccessPermission, 21.4.6.1
cloning environments, 5.2.1
commands to administer credentials, 9.3, 10.5
Complex queries, 23.2
Compliance, 12.1.1
configuration file, 21.4.9
configuration of multiple authenticators, 3.1.2.2
configureAccessGate tool, 17.4.2.1, 17.8.6
configuring
global logout
Oracle Access Manager, 17.1.2
Identity Assertion
for single sign-on with OAM, 16.2.4, 17.4
Oracle Web Services Manager, 16.2.6, 17.6
OAM Authenticator, 17.5
OAM for single-sign on with OAMCfgTool, 17.4.2.1
OAM for SSO with OAMCfgTool, 17.4.2
OSSO, 18.1
providers for Oracle Web Services Manager, 16.2.6.1, 17.6.2
Single Sign-On in Oracle Fusion Middleware, 15, 16, 17, 18
configuring domains, 5.4
configuring resource permissions, 20.3.4
configuring WebLogic domains, 5.4
CONNECTION_POOL_CLASS, L.6
createAppRole, 9.3.1, 9.3.2
createCred, 10.5.3
createResourceType, 9.3.12
creating user accounts, 2.6
credential migration settings, 6.2.1
credential store, 2.1
Credential Store Types, 3.3
CredentialAccessPermission, 21.4.6.2
CredentialMapping permission, 8.7.3.3
CSF
J2EE example with LDAP store, 24.7.4
J2EE example with wallet, 24.7.3
J2SE example with wallet, 24.7.2
CSIv2 identity assertion, 3.1.2.3
custom authorization providers, 3.2
cwallet.sso, 4.3, 6.2.1, 21, 21.4.3
cwallet.sso file, 21.3

D

DB-based credential store, 3.3
DB-based policy store, 8.3
DB-based security store, 4.1
DBMS_STATS, 8.3.2
debugging authorization, L.1.2.3
DefaultAuthenticator, 16.2.4.2.4, 16.2.5.1, 16.2.6.1, 17.4.3.3, 17.5.3, 17.6.2, 18.1.2.4
default.auth.level, 8.7.3.3
deleteAppPolicies, 9.3.11
deleteAppRole, 9.3.3
deleteResourceType, 9.3.14
deleting a role, 9.3.3
deployed application, 5.3
deploying applications, 6.1
deploying JavaEE applications, 6.4
deploying to a test environment, 6.3.1
deployment tools, 6.2
development mode, 21.4.4, 21.4.5.3
distribute environments, 8.2.1
DN, 2.7.2
doAs, 20.3.3.2
doAsPrivileged, 20.3.3.2
Dynamic authentication, 8.7.3.1

E

EAR file, 21.3, 21.3.1, 21.3.2
EJB Interceptor, 21.1
ejb-jar.xml, 3.2, 21.1, 21.3
embedded LDAP, 3.1.2, 4.2
enable.anonymous, 21.1
enterprise group, 2.1
Enterprise Groups and Users Class, 21.2
enterprise user, 2.1
Enterprise-Level SSO, 15.1
entitlement-based policies, 2.1
Event Source Type, 12.3.2
Existing OSSO, 15.1
exportAuditConfig, C.4.7
EXTRA_JAVA_PROPERTIES, F.1, L.1.2

F

fail over support, 5.4
FAQ, 1.1
file-based policy store, 3.2
file-based security store, 4.1

G

generic credential, 10.1
Generic LDAP Properties, F.2.4
getAuditPolicy, C.4.2
getGrantedResources, 20.3.3.4
getNonJavaEEAuditMBeanName, C.4.1
getPermissions, L.1.1.3.2
getResourceType, 9.3.13, 9.3.15, 9.3.15, 9.3.16, 9.3.16, 9.3.17, 9.3.17, 9.3.17, 9.3.18, 9.3.19, 9.3.19, 9.3.20, 9.3.20, 9.3.21, 9.3.21, 9.3.22, 9.3.22, 9.3.23, 9.3.23, 9.3.24, 9.3.24, 9.3.24, 9.3.25, 9.3.25, 9.3.26, 9.3.26, 9.3.27, 9.3.27, 9.3.28, 9.3.28
Global logout, 8.7.3.1
grant
permission-based, 2.2.1
grantAppRole, 9.3.4
GrantManager class, 20.3.2
grantPermission, 9.3.8
group, 2.1
GUID, 2.7.2

H

Headers
sent by Oracle HTTP Server, 18.1.1.3
host name verification, 3.1.2.2
hot deployed, 6.5.2

I

Identity Asserter for Single Sign-on with OAM, 15.2
identity store, 2.1
creating provider, 25.3.4
provider configuration properties, 25.3.5
selecting provider, 25.3.3
WebLogic, 3.1.2
WebSphere, 3.1.3
identity store in JavaSE, 22.2.2
Identity Store Service, 7.1
identity store types, 3.1.1
identity virtualization, 7.1.1
idstore.type, F.2.3
importAuditConfig, C.4.8
incompatible versions, L.21, L.22
initializing an LDAP authenticator, 3.1.2.2
invoking MBeans, E.2.2
isCallerInRole, 1.5.1
isUserInRole, 1.5.1, 20.2.2.2

J

JAAS mode, 21.1
Java component, 2.1
javadocs
OPSS APIs, H.1
OPSS MBeans APIs, H.1
OPSS User and Role APIs, H.1
JavaSE application, 23.1
java.security.policy, F.1
jazn-data.xml, 4.3, 6.2.1, 21, 21.3, 21.3.1
join, 9.3.29
JpsApplicationLifecycleListener, 21.4.4
jpsApplicationLifecycleListener, 21.4.1
jps.apppolicy.idstoreartifact.migration, 21.4.1, 21.4.1
jps.auth.debug, L.1.2.1
jps.auth.debug.verbose, L.1.2.2
jps-config-jse.xml, 1.5.3
jps-config.xml, 21, A
jps-config.xml example, 21.4.9
jps-config.xml full example, 21.4.9
jps.credstore.migration, 21.4.4
jps.deployment.handler.disabled, 8.6, 21.4
JpsFilter, 21.1, 21.3, L.1.1.5
JpsInterceptor, 21.1, 21.1.1, 21.3, L.1.1.5
JpsPermission, 21.4.6.3
jps.policystore.applicationid, 21.4.1
jps.policystore.hybrid.mode, F.1, F.1
jps.policystore.migration, 21.4.1
jps.policystore.migration.validate.principal, 21.4.1
jps.policystore.removal, 21.4.1

K

Keys and Certificates
managing, 11
Keystore Service, 11, 27
commands, 11.2

L

large volume stores, 6.5.2.3
LDAP Credential Store Properties, F.2.2
LDAP Identity Store Properties, F.2.3
LDAP Policy Store Properties, F.2.1
LDAP servers, 4.1
ldapadd, 8.2.2
LDAP-based policy store, 3.2, 8.2
ldapmodify, 8.5.1.1
ldapsearch, 8.2.2
LDIF file, 8.2.2
ldifwrite, 6.5.2.3
listAppRoleMembers, 9.3.7
listAppRoles, 9.3.6
listAuditEvents, C.4.6
listPermissions, 9.3.10
loggers
oracle.security.jps.trace.logger, L.1.1.3.2
oracle.security.jps.util.JpsAuth, L.1.1.3.1
logical role, 2.1, E.3
login.url.FORM, 8.7.3.3
logout.url, 8.7.3.3

M

management tools, 4.2
managing
keys and certificates, 4.2
policies and credentials, 4.2
managing credentials, 6.3.1, 6.3.1.1
managing domain authenticators, 5.4
managing identities, 4.2, 6.3.1
managing policies, 6.3.1
managing policies and credentials, 4.2
managing system policies, 6.3.1.1
managing users and groups, 4.2
Manually Configuring
WebGate Web Server, 16.2.3
mapping application roles to enterprise groups, 6.3.1.1
mapping of application roles, 2.2
mapping roles, 6.5.2
matcher class, 20.3.4
Matcher Class for a Resource Type, 20.3.4
MBean
Administration Policy Store, E.2.1
annotations, E.3.1
Application Policy Store, E.2.1
code sample, E.2.3
Credential Store, E.2.1
Global Policy Store, E.2.1
Jps Configuration, E.2.1
migrateSecurityStore, 6.5.1.1, 6.5.2, 8.6.2, 21.4.8, I.3
DB to DB, 6.5.2.1, 6.5.2.2
LDAP to LDAP, 6.5.2.1, 6.5.2.2
XML to LDAP, 6.5.2.1, 6.5.2.2
migrating credentials example, 6.5.2.2
Migrating Identities, 21.4.8
migrating identities manually, 6.5.1.1
migrating large stores, 6.5.2.3
migrating other providers, 6.5.1
migrating policies and credentials at deployment, 6.5.2
migrating policies example, 6.5.2.1
Migration of credentials, 3.3
Migration of policies, 3.2
mod_osso, 18.1.2, 18.3.1
modifyBootStrapCredential, 10.5.5
modifying a resource type, 9.3.14
Monitoring, 12.1.1
multiple-node server domain, 8.2.1

N

name comparison logic, 2.7.2

O

OAM
Authentication provider, 15.2, 15.2
parameter, 17.2
Troubleshooting, 17.8
Authenticator, 15.2, 16.2.5.1, 17.5.3
Identity Asserter, 15.2, 16.2.4.2.4, 16.2.6.1, 17.4.3.3, 17.6.2
OAM 10g SSO solution, 17
OAM 11g SSO solution, 16
OAM solution, 8.7.3.1
oamauthenticationprovider.war, 16.2.1, 17.1.1.2
oamAuthnProvider.jar, 15.2.5, 16.2.1, 16.2.1, 17.1.1.2, 17.1.1.2
OAMCfgTool, 17.1.1.1, 17.1.1.2, 17.4, 17.4.2
about using, 17.3
Create mode parameters, 17.3.2.1
host identifiers created, 17.3.3
Known Issues, 17.3.4
process overview, 17.3.1
Validate mode parameters, 17.3.2.2
oamcfgtool.jar, 15.2.5, 17.1.1.2
OID Authenticator, 16.2.4.2.4, 16.2.6.1, 17.4.3.3, 17.6.2, 18.1.1.2, 18.1.2.4
OID patches, 8.2
one-way SSL, 8.5.1
OPSS APIs
User and Role, D
OPSS security store, 2.1
OPSS SSO Framework, 8.7.3.1
OPSS System Properties, F.1
opss_purge_changelog, 8.3.2
Oracle Access Manager
Integration with OSSO, 15.1, 15.1
Oracle ADF security, 5.1
Oracle Business Intelligence Publisher, 14.1
audit report example, 14.4
Oracle Entitlements Server, 5.2, 5.5, 9, 9.1, 9.7
Oracle Fusion Middleware Audit Framework, 12.1, 12.1.3
architecture, 12.3.1
concepts, 12.3, 12.3.2
Oracle Information Lifecycle Management Assistant, 13.5.6.4
Oracle Internet Directory, 4.1
Oracle Internet Directory 10.1.4.3 patch, 4.1
Oracle Internet Directory tuning, 4.1
Oracle JDeveloper 11g, 5.1
Oracle Platform Security Services, 15.1
OracleAS Single Sign-On solution, See Also OSSO, 18.1
oracle.deployed.app.dir, B.2
oracle.deployed.app.ext, B.2
oracle.security.jps.config, 1.5.3, A
oracle.security.jps.jaas.mode, 21.1
oracle.security.jps.log.for.approle.substring, L.1.2.3
oracle.security.jps.log.for.enterprise.principalname, L.1.2.3
oracle.security.jps.log.for.permclassname, L.1.2.3
oracle.security.jps.log.for.permeffect, L.1.2.3
oracle.security.jps.log.for.permtarget.substring, L.1.2.3
Oracle-specific applications, 5.1
OSSO
existing implementation, 15.1
Identity Asserter, 18.1.1, 18.1.2.4, 18.1.2.4
new users, 18.1.2
processing, 18.1.1.2
Tips and Troubleshooting, 18.3
solution, 15.1, 15.1, 18
OSSO Identity Asserter, 18.1.1.1

P

packaging an J2EE application, 21.3
Packaging Credentials, 21.3.2
Packaging Policies, 21.3.1
password credential, 10.1
password validation, 2.6
passwords, 2.6
permission, 20.3.4
permission class, 20.3.4
permission classes, 3.2, 8, 21.4.6
permission inheritance, 2.2.1
permissions to anonymous role, 2.4
permissions to authenticated role, 2.3
PermissionSetManager class, 20.3.2
policy domain
URL prefixes, 17.5.2.1, 17.5.2.2, 17.6.1
policy migration settings, 6.2.1
Policy Store, 3.2
policy store, 2.1
policy store cache, 9.4
policy store removal, 3.2
PolicyStoreAccessPermission, 21.4.6.1
PolicyStoreIncompatibleVersionException, L.21, L.22
policystore.refresh.interval, 9.4
Post-installation tasks, 5.3
principal, 2.1
principal name comparison, 2.7.1, 2.7.2
principal.cache.key, 23.1.1
PrincipalEqualsCaseInsensitive, 2.7.2
PrincipalEqualsCompareDnAndGuid, 2.7.2
Procedure
WebGate
To manually configure a Web server, 16.2.3.2
Process overview
OAMCfgTool, 17.3.1
Oracle Access Manager Authenticator for Web and non-Web Resources, 15.2.2
OSSO Identity Asserter, 18.1.1.2
production environment, 5.2.1
props.auth.level, 8.7.3.3
props.auth.uri, 8.7.3.3
props.auth.url, 8.7.3.3

R

RCU, 8.3.1
reassociateSecurityStore, 9.3.29, I.3
Reassociation of credentials, 3.3
Reassociation of policies, 3.2
recovery of server files, 5.2
reference integrity, 3.1.1
referencial integrity, 8.2
remove.anonymous.role, 21.1
Resource Catalog, 20.3.1
resource permissions, 20.3.4
managing, 20.3.4
resource type, 20.3.4
resource-based policies, 2.1
ResourceManager class, 20.3.2
ResourcePermission class, 20.3.4
resourcetypeenforcementmode, F.2.1.1, F.2.1.2
ResourceTypeManager class, 20.3.2
revokeAppRole, 9.3.5
revokePermission, 9.3.9
role category, 2.8
role hierarchy, 2.2.1
RoleCategoryManager class, 2.8

S

SAML 1.1 identity assertion, 3.1.2
SAML 2.0 identity assertion, 3.1.2
scenarios, 4.4, 4.4
Security Provider Configuration, 8.5.1, 8.7
Security Provider for WebLogic SSPI, 15.2.3.3
security store, 2.1
security-related commands, 5.6
server restart, 4.2, F
service instance update script, E.1
Service Providers, 25.3
introduction, 25.3
understanding, 25.3.1
Set Security Provider, 8.5.1
setAuditPolicy, C.4.3
setAuditRepository, C.4.5
setDomainEnv shell script, F.1, L.1.2
setPolicy, 20.3.3, 20.3.3.3
Setting a Node in LDAP server, 8.2.2
setting up providers
OAM Asserter with Oracle Web Services Manager, 16.2.6.1
OAM Authenticator, 16.2.5.1
OAM Identity Assertion, 16.2.4.2.4, 17.4.3.3
OSSO Identity Asserter, 18.1.2.4
Single Sign-On, 8.7.3
single sign-on solutions for Fusion Middleware, See Also SSO, 15
split profiles, 7.3.3
SPNEGO, 3.1.2.3
SPNEGO tokens, 3.1.2.3
SSL
and User/Role APIs, 25.8
anonymous, 8.5.1
one-way, 8.5.1
SSL to a DB, 8.3.3
SSO
enterprise level, 15.1
existing 10g SSO, 15.1
Oracle Access Manager, 15.2
Synchronization Filter, 16.4, 17.7, 18.2
SSO Logout URL, 16.3.1
SSO service, 8.7.3.1
SSO service configuration, 8.7.3.3
sso.provider.class, 8.7.3.3
storing policies and credentials, 4.1
subject, 2.1, 2.4.1, 2.7.1
supported
identity store types, 3.1.1
synchronizing
user and SSO Sessions, 16.4, 17.7, 18.2
system component, 2.1
system-jazn-data.xml, 21

T

Task overview
Configuring the OAM Authenticator, 16.2.5, 17.5
Deploying and configuring OAM Identity Assertion for single sign-on includes, 16.2.4, 17.4
Deploying OSSO Identity Asserter, 18.1.2
Deploying the Identity Asserter with Oracle Web Services Manager, 16.2.6, 17.6
Installing required components for OAM Authentication Provider, 16.2.1, 17.1.1.2
test environments, 6.3
token.provider.class, 8.7.3.3
troubleshooting
search fails against Microsoft Active Directory, L.20
typical security practices, 5.3

U

Unsupported Methods in PS2, 23.2
updateServiceInstanceProperty, E.1
updating instance with script, E.1
upgradeSecurityStore, G
URL
SSO Logout URL, 16.3.1
User and Role API, D
Javadoc, 25.9
programming tips, 25.3.9.1
User and Role APIs
and WebLogic authenticators, 25.1.1
environment setup, 25.3.2
introduction, 25.1
programming tips, 25.3.9
summary, 25.2
User and Role SPI
Javadoc, 25.10.7.4
UseRetrievedUserNameAsPrincipal, 3.1.2.2
user.login.attr, L.7
username.attr, L.7

V

virtualize, 7.3.1.1, 7.3.2, 7.3.2.3, F.2.3
virtualized identity, 7.1.1

W

WAR file, 21.1
WebLogic
Authentication provider, 15.1, 16.2.4.2.1, 17.4.3.1
Authentication providers
Identity Assertion, 16.2.4.2.1, 17.4.3.1
J2EE applications, 15.2.3.3
WebLogic Administration Console, 4.2
WebLogic Scripting Tool (WLST), 16.2.4.2.2, 17.4.3.2
weblogic-application.xml, 21
web.xml, 3.2, 21, 21.1, 21.3
WLSGroupImpl, 2.2.1, 9.3.4, 9.3.5, 21.2, 22.3
WLST
createAppRole, 9.3.1, 9.3.2
createCred, 10.5.3
createResourceType, 9.3.12
deleteAppPolicies, 9.3.11
deleteAppRole, 9.3.3
deleteCred, 10.5.4
deleteResourceType, 9.3.14
getResourceType, 9.3.13, 9.3.15, 9.3.15, 9.3.16, 9.3.16, 9.3.17, 9.3.17, 9.3.17, 9.3.18, 9.3.19, 9.3.19, 9.3.20, 9.3.20, 9.3.21, 9.3.21, 9.3.22, 9.3.22, 9.3.23, 9.3.23, 9.3.24, 9.3.24, 9.3.24, 9.3.25, 9.3.25, 9.3.26, 9.3.26, 9.3.27, 9.3.27, 9.3.28, 9.3.28
grantAppRole, 9.3.4
grantPermission, 9.3.8
listAppRoleMembers, 9.3.7
listAppRoles, 9.3.6
listCred, 10.5.1
listPermissions, 9.3.10
reassociateSecurityStore, 9.3.29
revokeAppRole, 9.3.5
revokePermission, 9.3.9
updateCred, 10.5.2
WLSUserImpl, 2.2.1, 21.2, 22.3

X

X509 identity assertion, 3.1.2
PK] 7-PKfp@ OEBPS/toc.htm Table of Contents

Contents

List of Examples

List of Figures

List of Tables

Title and Copyright Information

Preface

What's New in This Guide

Part I Understanding Security Concepts

1 Introduction to Oracle Platform Security Services

2 Understanding Users and Roles

3 Understanding Identities, Policies, Credentials, Keys, and Certificates

4 About Oracle Platform Security Services Scenarios

Part II Basic OPSS Administration

5 Security Administration

6 Deploying Secure Applications

Part III Advanced OPSS Administration

7 Configuring the Identity Store Service

8 Configuring the OPSS Security Store

9 Managing the Policy Store

10 Managing the Credential Store

11 Managing Keys and Certificates with the Keystore Service

12 Introduction to Oracle Fusion Middleware Audit Framework

13 Configuring and Managing Auditing

14 Using Audit Analysis and Reporting

Part IV Single Sign-On Configuration

15 Introduction to Single Sign-On in Oracle Fusion Middleware

16 Configuring Single Sign-On with Oracle Access Manager 11g

17 Configuring Single Sign-On Using Oracle Access Manager 10g

18 Configuring Single Sign-On using OracleAS SSO 10g

Part V Developing with Oracle Platform Security Services APIs

19 Integrating Application Security with OPSS

20 The OPSS Policy Model

21 Manually Configuring Java EE Applications to Use OPSS

22 Authentication for Java SE Applicaitons

23 Authorization for Java SE Applications

24 Developing with the Credential Store Framework

25 Developing with the User and Role API

26 Developing with the Identity Directory API

27 Developing with the Keystore Service

28 Developing with the Audit Service

Part VI Appendices

A OPSS Configuration File Reference

B File-Based Identity and Policy Store Reference

C Oracle Fusion Middleware Audit Framework Reference

D User and Role API Reference

E Administration with WLST Scripting and MBean Programming

F OPSS System and Configuration Properties

G Upgrading Security Data

H References

I OPSS Scripts

J Using an OpenLDAP Identity Store

K Adapter Configuration for Identity Virtualization

L Troubleshooting Security in Oracle Fusion Middleware

Index

PKIҮPKfp@'OEBPS/img_text/create_policy_domain.htmE Description of the illustration create_policy_domain.gif

Surrounding text describes this screen.

PK8#ʿPKfp@OEBPS/img_text/jisec015.htmO Description of the illustration jisec015.gif

The following text describes this figure.

PKFk:PKfp@'OEBPS/img_text/oam_sample_login_sso.htmD Description of the illustration oam_sample_login_sso.gif

Surrounding text describes this graphic.

PK"PKfp@OEBPS/img_text/jisec033.htmL Description of the illustration jisec033.gif

This diagram is described in following text.

PK2`2ٸPKfp@OEBPS/img_text/accessgate.htmN Description of the illustration accessgate.gif

Surrounding text describes this graphic.

PK\ڲնPKfp@OEBPS/img_text/authz_rules.htmM Description of the illustration authz_rules.gif

Surrounding text describes this graphic.

PKʅPKfp@OEBPS/img_text/host_ids.htmP Description of the illustration host_ids.gif

Surrounding text describes this graphic.

PK1xPKfp@OEBPS/img_text/jisec_dt_030.htmL Description of the illustration jisec_dt_030.gif

Surrounding text describes this graphic.

PK3PKfp@OEBPS/img_text/resources.htmO Description of the illustration resources.gif

Surrounding text describes this graphic.

PK<@PKfp@OEBPS/img_text/cafintro1.htm_ Description of the illustration cafintro1.gif

Oracle BI Publisher page

PKj~ PKfp@OEBPS/img_text/general.htmQ Description of the illustration general.gif

Surrounding text describes this graphic.

PKXPKfp@OEBPS/img_text/audrepos1.htm^ Description of the illustration audrepos1.gif

Audit store configuration

PKjPKfp@#OEBPS/img_text/delegated_admins.htmH Description of the illustration delegated_admins.gif

Surrounding text describes this graphic.

PK[LOPKfp@ OEBPS/img_text/default_rules.htmK Description of the illustration default_rules.gif

Surrounding text describes this graphic.

PKS=PKfp@OEBPS/img_text/policies.htmP Description of the illustration policies.gif

Surrounding text describes this graphic.

PKmPKfp@OEBPS/osso_d_10g.htm Configuring Single Sign-On using OracleAS SSO 10g

18 Configuring Single Sign-On using OracleAS SSO 10g

The chapter describes how to implement SSO using OracleAS SSO (OSSO) 10g. It includes the following major sections:

18.1 Deploying the OracleAS 10g Single Sign-On (OSSO) Solution

The OracleAS Single Sign-On solution provides single sign-on access to Web Applications. Oracle Internet Directory is the LDAP-based repository.

This solution is intended for applications that have been deployed on Oracle WebLogic Server but do not yet have single sign-on implemented. Requirements and steps to configure the OSSO solution are explained in "New Users of the OSSO Identity Asserter".


Note:

Oracle recommends using Oracle Access Manager 11g, as described in "Introduction to Oracle Access Manager 11g SSO".

Applications that are already using the OracleAS Single Sign-On solution with the JPS login module and dynamically re-directing requests to OSSO are unaffected by the new OSSO solution. In this case, there is no need to configure the new OSSO Authentication Provider described in this section.

This section is divided as follows:

18.1.1 Using the OSSO Identity Asserter

This section describes the expected behavior when you implement the OracleAS Single Sign-On Identity Asserter. This section is divided as follows:

18.1.1.1 Oracle WebLogic Security Framework

Figure 18-1 illustrates the location of components in the Oracle WebLogic Security Framework, including the OSSO Identity Asserter. Additional details follow.

At the top of the figure, Oracle HTTP Server is installed. This installation includes mod_weblogic and mod_osso, which are required to pass the identity token to the Providers and Oracle WebLogic Server. The Oracle WebLogic Server includes the partner application and the Identity Asserter (also known as the Identity Assertion Provider). The 10g OracleAS Single Sign-On server (OSSO Server), on the right side of the figure, communicates directly with the directory server and Oracle HTTP Server.


Note:

For simplicity in text, this chapter uses the generic name of the WebLogic Server plug-in for Apache: mod_weblogic. For Oracle HTTP Server, the name of this plug-in differs from release 10g to 11g:
  • Oracle HTTP Server 10g: mod_wl (actual binary name is mod_wl_20.so)

  • Oracle HTTP Server 11g: mod_wl_ohs (actual binary name is mod_wl_ohs.so)


18.1.1.2 OSSO Identity Asserter Processing

Figure 18-2 illustrates the processing that occurs when you have OSSO implemented with the Identity Asserter. Additional details follow the figure.

The first time a request for a protected resource arrives at the mid-tier Web server, the request is redirected to the 10g OracleAS Single Sign-On server, which requires user credentials For a certificate-based authentication, no login page is displayed. After the user has been successfully authenticated, all further requests from that user require only that the user identity be asserted by the OSSO Identity Asserter before the population of a JAAS Subject takes place. The Subject is consumed by the downstream applications.

For example, suppose you have an application residing on an Oracle WebLogic Server that is front-ended with the Oracle HTTP Server. The application is protected using resource mappings in the mod_osso configuration. This case is described in the following process overview.

Process overview: OSSO Identity Asserter

  1. The user requests a protected application.

  2. The Oracle HTTP Server intercepts the request and processes it using mod_osso to check for an existing, valid Oracle HTTP Server cookie.

  3. If there is no valid Oracle HTTP Server cookie, mod_osso redirects to the OracleAS SSO Server, which contacts the directory during authentication.

  4. After successful authentication mod_osso decrypts the encrypted user identity populated by the OSSO server and sets the headers with user attributes.

  5. mod_weblogic completes further processing and redirects the request to the Oracle WebLogic Server.

  6. The WebLogic security layer invokes providers depending on their settings and the order specified. For example: the security layer invokes the:

  7. A response is sent to the user through the Oracle HTTP Server, and access to the application is granted.

18.1.1.3 Consumption of Headers with OSSO Identity Asserter

This topic describes the headers sent by Oracle HTTP Server and the tokens set in the header and the headers consumed by the OSSO Identity Asserter. If the application needs to use the JAAS subject, configure OSSO Identity Asserter.

Table 18-1 provides the list of headers set by Oracle HTTP Server (mod_osso and mod_weblogic). An application whose logic consumes the JAAS subject for identifying user information, should be configured to use the OSSO Identity Asserter. which uses the OracleAS SSO token type set in bold in the table (Proxy-Remote-User). The OSSO Identity Asserter looks for the Proxy-Remote-User header and asserts the user's identity. The follow up OID Authenticator populates the JAAS subject.

Applications that do not require the JAAS subject for identifying user information, can read the headers directly using the request.getHeader() API. Such applications are free to read any header they need. Headers with user info are Osso-User-Dn, Osso-User-Guid, and Proxy-Remote-User.

18.1.2 New Users of the OSSO Identity Asserter

The new OracleAS Single Sign-On solution includes the OSSO Identity Asserter, one of the two new Authentication Providers for the Oracle WebLogic Server.

To have your application use the OSSO solution, you need the components described in the following task.


Note:

If you already have components installed and set up, you do not need more. You can skip any steps that do not apply to your deployment.

Task overview: Deploying and configuring the OSSO Identity Asserter

  1. Install the following components:

    1. OracleAS Single Sign-On Server 10g (10g OSSO server


      See Also:

      Oracle Application Server Installation Guide on Oracle Technology Network at: http://www.oracle.com/technology/documentation/oim1014.html

    2. An Oracle Internet Directory repository configured to be used by the 10g OSSO server. Ensure that the directory server is tuned for your deployment.

    3. One of the following Web servers (based on Apache 2):

    4. Oracle WebLogic Server 10.3.1+

    5. An Oracle Fusion Middleware product such as Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter is required; it includes the provider required for OSSO by Oracle WebLogic Server in the following path:

      ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar
      
  2. Configure mod_weblogic so that it forwards requests to Oracle WebLogic Server, as explained in section "Configuring mod_weblogic".

  3. Register the module mod_osso with the 10g SSO Server as a partner application, as described in "Registering Oracle HTTP Server mod_osso with OSSO Server 10.1.4".

  4. Configure mod_osso, as described in "Configuring mod_osso to Protect Web Resources".

  5. Add the OSSO Identity Asserter to the appropriate domain, as explained in section "Adding Providers to a WebLogic Domain for OSSO".

  6. Configure a connection filter, as explained in section "Establishing Trust Between Oracle WebLogic Server and Other Entities".

  7. Configure the use of the solution by the application, as explained in section "Configuring the Application for the OSSO Identity Asserter".

  8. Identify and resolve issues with your OSSO Identity Asserter implementation, see "Troubleshooting for an OSSO Identity Asserter Deployment".

18.1.2.1 Configuring mod_weblogic

You can either edit the Oracle HTTP Server httpd.conf file directly or add mod_weblogic configuration in a separate file and include that file in httpd.conf.

The following procedure includes steps for two different Web server releases. Perform steps as needed for your deployment:

  • OHS 11g ships with mod_wl_ohs.so. In this case, skip Step 1.

  • OHS 10g does not ship with mod_weblogic (mod_wl_.so). If Oracle HTTP Server 10g is installed, start with Step 1 to copy mod_wl_20.so before configuration.


Note:

For Oracle HTTP Server, the name of this plug-in differs from release 10g to 11g:
  • Oracle HTTP Server 10g: mod_wl (actual binary name is mod_wl_20.so)

  • Oracle HTTP Server 11g: mod_wl_ohs (actual binary name is mod_wl_ohs.so)


To install and configure mod_weblogic

  1. Oracle HTTP Server 10.1.3: Copy mod_wl_20.so to the Oracle HTTP Server modules directory: For example:

    From: WL_HOME/wlserver_10.0/server/plugin/linux/i686

    To: ORACLE_HOME/ohs/modules

  2. Locate the Oracle HTTP Server httpd.conf file. For example:

    Oracle HTTP Server 10.1.3:

    ORACLE_HOME/ohs/conf/httpd.conf
    

    Oracle HTTP Server 11g:

    ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
    
  3. Verify that mod_weblogic configuration is in httpd.conf, either by inclusion of the appropriate configuration file or the configuration itself directly. For example, for Oracle HTTP Server 10g:

    LoadModule weblogic_module ${ORACLE_HOME}/ohs/modules/mod_wl_20.so 
    <IfModule mod_weblogic.c>
       WebLogicHost yourHost.yourDomain.com
         WebLogicPort yourWlsPortNumber
    </IfModule>
     
    <Location /request-uri-pattern>
       SetHandler weblogic-handler
    </Location>
    

18.1.2.2 Registering Oracle HTTP Server mod_osso with OSSO Server 10.1.4

The mod_osso module is an Oracle HTTP Server module that provides authentication to OracleAS applications. This module resides on the Oracle HTTP Server that enables applications protected by OracleAS Single Sign-On to accept HTTP headers in lieu of a user name and password once the user has logged into the OracleAS Single Sign-On server. The values for these headers are stored in a mod_osso cookie.

The mod_osso module enables single sign-on for Oracle HTTP Server by examining incoming requests and determining whether the requested resource is protected. If it is, then it retrieves the Oracle HTTP Server cookie.

Under certain circumstances, you must register Oracle HTTP Server mod_osso using the 10.1.4 Oracle Identity Manager single sign-on registration tool (ssoreg.sh or ssoreg.bat). Table 18-2 provides a summary of parameters and values for this purpose. Running the tool updates the mod_osso registration record in osso.conf. The tool generates this file whenever it runs.

Table 18-2 ssoreg Parameters to Register Oracle HTTP Server mod_osso

ParameterDescription

-oracle_home_path

Path to the 10.1.4 SSO Oracle_Home

-site_name

Any site name to be covered

-config_mod_osso

TRUE. If set to TRUE, this parameter indicates that the application being registered is mod_osso. You must include config_mod_osso for osso.conf to be generated.

-mod_osso_url

URL for front-ending Oracle HTTP Server Host:port. This is the URL that is used to access the partner application. The value should be specified in the URL format:http://oracle_http_host.domain:port

-update_mode

Optional. CREATE, the default, generates a new record.

-remote_midtier

Specifies that the mod_osso partner application to be registered is at a remote mid-tier. Use this option only when the mod_osso partner application to be configured is at a different ORACLE_HOME, and the OracleAS Single Sign-On server runs locally at the current ORACLE_HOME.

-config_file

Path where osso.conf is to be generated

[-admin_info

Optional. User name of the mod_osso administrator. If you omit this parameter, the Administer Information field on the Edit Partner Application page is left blank.

admin_id

Optional. Any additional information, such as email address, about the administrator. If you omit this parameter, the Administrator E-mail field on the Edit Partner Application page is left blank.

<VirtualHost ...>

Host name. Optional. Include this parameter only if you are registering an Oracle HTTP virtual host with the single sign-on server. Omit the parameter if you are not registering a virtual host.

If you are creating an HTTP virtual host, use the httpd.conf file to fill in the directive for each protected URL.



See Also:

The following books on Oracle Technology Network at: http://www.oracle.com/technology/documentation/oim1014.html
  • Oracle Application Server Single Sign-On Administrator's Guide 10g (10.1.4.0.1) Part Number B15988-01

  • Oracle Identity Management Application Developer's Guide 10g (10.1.4.0.1) Part Number B15997-01


The following procedure includes a sample command to register mod_osso. Values for your environment will be different.

To register mod_osso

  1. Go to the following 10.1.4 Oracle Identity Manager directory path:

    ORACLE_HOME/sso/bin/ssoreg
    
  2. Run ssoreg with the following parameters and values for your environment. For example, on Unix, this might look like:

    ./ssoreg.sh -oracle_home_path \OraHome -site_name wls_server  
    -config_mod_osso TRUE -mod_osso_url http://oracle_http_host.domain:7788 
    -update_mode CREATE -remote_midtier -config_file \tmp\osso.conf
    
  3. Verify that the module mod_osso of the required Oracle HTTP Server is registered.

  4. Proceed to "Configuring mod_osso to Protect Web Resources".

18.1.2.3 Configuring mod_osso to Protect Web Resources

mod_osso redirects the user to the single sign-on server only if the URL you request is configured to be protected. You can secure URLs in one of two ways: statically or dynamically. Static directives simply protect the application, ceding control over user interaction to mod_osso. Dynamic directives not only protect the application, they also enable it to regulate user access.

For more information, see:

18.1.2.3.1 Configuring mod_osso with Static Directives

You can statically protect URLs with mod_osso by applying directives to the mod_osso.conf file. You must configure mod_osso to ensure that requests are intercepted properly. In addition, you specify the location of protected URIs, time out interval, and the authentication method. Oracle recommends that you place in the httpd.conf file the include statement for mod_osso.conf before the one wherein the weblogic_module statement is loaded.

The following procedure describes how to configure mod_osso by editing the mod_osso.conf file. This procedure provides details for two different releases. Ensure that you follow instructions for your OHS deployment:

  • Oracle HTTP Server 11g: Requires Step 2 and AuthType Osso in Step 4. The path name in Step 5 differs for Oracle HTTP Server 11g.

  • Oracle HTTP Server 10g: Requires Step 3 and AuthType Basic in Step 4. The path name in Step 5 differs for Oracle HTTP Server 10g.

To configure mod_osso to protect Web resources

  1. Copy osso.conf from the location where it was generated to the following location:

    From: /tmp/osso.conf

    To:

    ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf  
    
  2. Oracle HTTP Server 11g: Copy mod_osso.conf from the disabled directory to the moduleconf directory for editing. For example:

    From:

    ORACLE_INSTANCE/config/OHS/<ohs_name>/disabled/mod_osso.conf  
    

    To:

    ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf  
    
  3. Oracle HTTP Server 10g: Locate mod_osso.conf for editing. For example:

    ORACLE_HOME/ohs/conf/mod_osso.conf
    
  4. Edit mod_osso.conf to add the following information using values for your deployment. For example, using Oracle HTTP Server as an example (paths are different for 10g):

    LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
    <IfModule mod_osso.c>
    
    OssoIdleTimeout off
    OssoIpCheck on
    OssoConfigFile  ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf   
    
    #Location is the URI you want to protect
    <Location />
    require valid-user
    #OHS 11g AuthType Osso    
    #OHS 10g AuthType Basic    
    AuthType Osso
    
    </Location>
    
    </IfModule>
    
  5. Locate the httpd.conf file for editing. For example:

    Oracle HTTP Server 10.1.3:

    ORACLE_HOME/ohs/config/httpd.conf
    

    Oracle HTTP Server 11g:

    ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf 
     
    
  6. In the httpd.conf, confirm that the mod_osso.conf file path for your environment is included. For example:

    include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
    
  7. Restart the Oracle HTTP Server.


    Tip:

    If the interception of requests is not working properly, consider placing the include statement for mod_osso.conf before the LoadModule weblogic_module statement in the httpd.conf.

  8. Proceed to "Adding Providers to a WebLogic Domain for OSSO".

18.1.2.3.2 Protecting URLs and Logout Dynamically (without mod_osso)

Applications that use dynamic directives require no entry in mod_osso.conf because mod_osso protection is written directly into the application as one or more dynamic directives.

Dynamic directives are HTTP response headers that have special error codes that enable an application to request granular functionality from the single sign-on system without having to implement the intricacies of the single sign-on protocol. Upon receiving a directive as part of a simple HTTP response from the application, mod_osso creates the appropriate single sign-on protocol message and communicates it to the single sign-on server.

OracleAS supports dynamic directives for Java servlets and JSPs. The product does not currently support dynamic directives for PL/SQL applications. The JSPs that follow show how such directives are incorporated. Like their "static" counterparts, these sample "dynamic" applications generate user information:


Note:

After adding dynamic directives, be sure to restart the Oracle HTTP Server, and the proceed to "Adding Providers to a WebLogic Domain for OSSO".


See Also:

Oracle Identity Management Application Developer's Guide 10g (10.1.4.0.1) Part Number B15997-01 on Oracle Technology network at: http://www.oracle.com/technology/software/products/ias/htdocs/101401.html


See Also:



Note:

After adding dynamic directives, be sure to restart the Oracle HTTP Server, and the proceed to "Adding Providers to a WebLogic Domain for OSSO".

18.1.2.4 Adding Providers to a WebLogic Domain for OSSO

You must add the OSSO Identity Asserter to a WebLogic domain. In addition to the OSSO Identity Asserter, Oracle recommends the following Authentication Providers:

You can add providers using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.

The following procedure illustrates adding Authentication Providers using the Oracle WebLogic Administration Console. Before you begin, there is a condition to pay attention to:

Step 10: If your application requires the user in the same case as in Oracle Internet Directory (uppercase, lowercase, initial capitals), check Use Retrieved User Name as Principal. Otherwise, leave it unchecked.

To add providers to your WebLogic domain for OSSO Identity Assertion

  1. Log in to the WebLogic Administration Console.

  2. OSSO Identity Asserter: Perform the following steps to add this to the domain:

    1. Click Security Realms, Default Realm Name, Providers.

    2. Select New under the Authentication Providers table.

    3. Enter a name for the new provider, select its type, and then click OK. For example:

      Name: OSSO Identity Asserter

      Type: OSSOIdentityAsserter

      Ok

    4. Click the name of the newly added provider.

    5. On the Common tab, set the appropriate values for common parameters and set the Control Flag to SUFFICIENT and then save the settings.

  3. Default Authentication Provider:

    1. Click Security Realms, Default Realm Name, Providers.

    2. Click Default Authentication Provider.

    3. Set the control flag to OPTIONAL, and click Save

  4. OID Authenticator: Perform the following steps to add this provider.

    1. Click Security Realms, Default Realm Name, Providers.

    2. Click New, and enter a name and type:.

      Name. OID Authenticator

      Type: OracleInternetDirectoryAuthenticator

      Click Save.

    3. Click the newly added authenticator to see the Settings page. Retain the default settings; do not change the Control Flag until you have verified that the Oracle Internet Directory configuration is valid.


      Note:

      If OID Authenticator is the only provider, ensure the WebLogic Server user account and its granted group memberships are created in Oracle Internet Directory. Otherwise the WebLogic domain does not start properly.

    4. Click the Provider Specific tab and specify the following required settings:

      Propagate Cause For Login Exception: Check

      Principal: LDAP administrative user. For example: cn=orcladmin

      Host: The Oracle Internet Directory hostname

      Use Retrieved User Name as Principal: Check

      Credential: LDAP administrative user password. For example: password

      Confirm Credential: For example: password

      Group Base DN: Oracle Internet Directory group search base

      User Base DN: Oracle Internet Directory user search base.

      Port: Oracle Internet Directory port

  5. Reorder Providers: The order in which providers populate a subject with principals is significant and you might want to reorder the list of all providers in your realm and bring the newly added provider to the top of the list.

  6. Save all configuration settings.

  7. Stop and restart the Oracle WebLogic Server for the changes to take effect.

  8. Log in to the WebLogic Administration Console:

    1. Click Security Realms, Default Realm Name, Providers.

    2. Select the Users and Groups tab to see a list of users and groups contained in the configured Authentication Providers.

      You should see usernames from the Oracle Internet Directory configuration, which implicitly verifies that the configuration is working.

      --If the Oracle Internet Directory instance is configured successfully, you can change the Control Flag.

      --If the Oracle Internet Directory authentication is sufficient for an application to identify the user, then choose the SUFFICIENT flag. SUFFICIENT means that if a user can be authenticated against Oracle Internet Directory, no further authentication is processed. REQUIRED means that the Authentication Provider must succeed even if another provider already authenticated the user.

  9. Application Requires User in Same Case as in Oracle Internet Directory: Check Use Retrieved User Name as Principal. Otherwise, leave it unchecked.

  10. Save the changes.

  11. Activate the changes and restart Oracle WebLogic Server.

  12. Proceed with "Establishing Trust Between Oracle WebLogic Server and Other Entities".

18.1.2.5 Establishing Trust Between Oracle WebLogic Server and Other Entities

The Oracle WebLogic Connection Filtering mechanism must be configured for creating access control lists and for accepting requests from only the hosts where Oracle HTTP Server and the front-end Web server are running.


Note:

This topic is the same whether you are using OSSO or Oracle Access Manager. In the WebLogic Administration Console.

A network connection filter is a component that controls the access to network level resources. It can be used to protect resources of individual servers, server clusters, or an entire internal network. For example, a filter can deny non-SSL connections originating outside of a corporate network. A network connection filter functions like a firewall since it can be configured to filter protocols, IP addresses, or DNS node names. It is typically used to establish trust between Oracle WebLogic Server and foreign entities.

Connection Filter Rules: The format of filter rules differ depending on whether you are using a filter file to enter the filter rules or you enter the filter rules in the Administration Console. When entering the filter rules on the Administration Console, enter them in the following format:

targetAddress localAddress localPort action protocols

See Also:

"Configuring Security in a WebLogic Domain" in Oracle Fusion Middleware Securing Oracle WebLogic Server

Table 18-3 provides a description of each parameter in a connection filter.

The Connection Logger Enabled attribute logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.

To configure a connection filter to allow requests from the host of the 11g Oracle HTTP Server

  1. Log in to the Oracle WebLogic Administration Console.

  2. Click Domain under Domain Configurations.

  3. Click the Security tab, click the Filter tab.

  4. Click the Connection Logger Enabled attribute to enable the logging of accepted messages for use when debugging problems relating to server connections.

  5. Specify the connection filter to be used in the domain:

    • Default Connection Filter: In the Connection Filter attribute field, specify weblogic.security.net.ConnectionFilterImpl.

    • Custom Connection Filter: In the Connection Filter attribute field, specify the class that implements the network connection filter, which should also be specified in the CLASSPATH for Oracle WebLogic Server.

  6. Enter the appropriate syntax for the connection filter rules.

  7. Click Save.

  8. Restart the Oracle WebLogic Server.

  9. Proceed to "Configuring the Application for the OSSO Identity Asserter".

18.2 Synchronizing the User and SSO Sessions: SSO Synchronization Filter

In Fusion Middleware 11g, a new component that synchronizes the container user session and SSO session has been introduced. SSO Sync Filter is an Oracle WebLogic system filter implementation that intercepts all requests to the container, acts on protected resource requests, and attempts to synchronize the container's user session with the user identifying header in OSSO (Proxy-Remote-User) or the user data in the Oracle Access Manager SSO session cookie (ObSSOCookie).

SSO Synchronization Filter (SSO Sync Filter) is an implementation of the Servlet Filter based on Java Servlet Specification version 2.3. SSO sync filter relieves applications from tracking the SSO user session and synchronizing it with their respective sessions. Instead, applications would only need to synchronize with container's user session.

SSO Sync Filter intercepts each request to the container and determines whether to act on it based on certain HTTP headers that are attached to the request. Filter expects SSO agent to have set those headers in the Web Tier. When access is made to unprotected areas of the application, the filter acts as a pass through. Once a protected resource is accessed, SSO agents in the Web Tier, direct user to perform authentication with SSO system such as Oracle Access Manager. After the authentication, Oracle Access Manager Identity Asserter helps establish a user identity in form of JAAS Subject to the container and a user session is created. WebLogic maintains the user session data as part of HTTP Session Cookie (JSESSIONID).

Subsequent access to the application resources provides two pieces of information to the SSO Sync Filter:

  • User identifying header in OSSO (Proxy-Remote-User)

  • User data in the Oracle Access Manager SSO session cookie (ObSSOCookie)

The job of SSO Sync Filter is to make sure that the user identity in the container matches with that of the SSO session. If there is a mismatch, filter invalidates the container's user session. As a result, the downstream application would only have to track container user session and react in a consistent fashion regardless of SSO environment in use.

Notes:

You can alter the behavior of the SSO Sync Filter for application requirements by passing various over-riding system properties to WebLogic. To do this, you change the Oracle WebLogic startup script and check for EXTRA_JAVA_PROPERTIES in setDomainEnv.sh. The properties and Sync behavior is shown in Table 18-4.

You cannot enable the filter for selected applications. The SSO Sync Filter is a system filter. As such, it is activated for all deployed applications (the URI mapping is /*).


Note:

You cannot enable the filter for selected applications.

The following procedure gives some tips about modifying the SSO Sync filter properties and behavior.

To modify the SSO Sync Filter properties and behavior

  1. Disable the Filter: Change the system property "sso.filter.enable" to "false" (pass as -D to the jvm) and restart the Oracle WebLogic Server. This toggles the filter status.

  2. User-Identifying Header Differs from Pre-Configured Sync Filter Tokens: Over-ride the SSO token that the Sync Filter looks for using the system property "sso.filter.ssotoken".

    For example, pass to the WebLogic Server jvm in the WebLogic Server startup script -Dsso.filter.ssotoken=HEADERNAME, and restart the server.

When you contact Oracle Support you might be requested to set up debugging, as described in "Setting Up Debugging in the WebLogic Administration Console".

18.3 Troubleshooting for an OSSO Identity Asserter Deployment

The troubleshooting items described in this section are grouped into the following categories:


See Also:


18.3.1 SSO-Related Problems

This section addresses the following troubleshooting items:

OHS Is Not Redirecting to SSO - Internal Server Error 500

The most likely source of this problem is an incorrect configuration.

The following sample uses Oracle HTTP Server 11g. Path names are different if you have Oracle HTTP Server 10g.

To address it, proceed as follows:

  1. Open the file mod_osso.conf and ensure that the resource is protected. For example:

    ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf  
    
    <Location /protected-resource-uri>
    require valid-user
    AuthType Basic
    </Location>
    
  2. Ensure that osso.conf is present and included in mod_osso.conf. For example, using Oracle HTTP Server 11g (paths are different for 10g)

    OssoConfigFile  ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf  
    

    Note:

    There is no set location for osso.conf. The value is determined at registration time; it can be any absolute path.

  3. Ensure that httpd.conf includes mod_osso.conf. For example, using Oracle HTTP Server 11g (paths are different for 10g):

    ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
    
    include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
    
  4. If all of the above were correctly specified, the SSO registration did not complete successfully and you must re-register SSO.

    To register SSO, proceed as follows using the appropriate ssoreg tool for your platform. For example:

    1. Run ssoreg.sh in 10.1.4 ORACLE_HOME/sso/bin to produce the file osso.conf. The following is a sample usage of this utility that produces the file in /tmp/osso.conf (the arguments are displayed in different lines only for illustration):

      >ssoreg.sh -oracle_home_path /OraHome 
                 -site_name wls_server 
                 -config_mod_osso TRUE 
                 -mod_osso_url http://host.domain.com:6666 
                 -update_mode CREATE 
                 -remote_midtier 
                 -config_file /tmp/osso.conf
      
    2. Copy the generated osso.confto another file system directory. For example: ORACLE_INSTANCE/config/OHS/<ohs_name>/osso.

    3. Restart OHS.

Is Attribute AuthName Required?

Log messages might suggest that the attribute AuthName is required, and certain versions of Apache do require this attribute.

This example uses Oracle HTTP Server 11g. Path names are different for Oracle HTTP Server 10g.

To include this attribute, edit the file mod_osso.conf and insert a fragment like the following:

LoadModule osso_module modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile  ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
 
<Location />
AuthName "Oracle Single Sign On"
require valid-user
AuthType Basic
</Location>
</IfModule>

URL Request not Redirected to SSO

Once a URL request is issued, if a basic pop-up is displayed instead of being redirected to SSO, then, most likely, the URL request has been intercepted by the Apache authorization module.

To address this problem, proceed as follows:

  1. Edit the file httpd.conf and comment out the loading authorization modules as illustrated in the following fragment:

    ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
    
    LoadModule access_module modules/mod_access.so
    #LoadModule auth_module modules/mod_auth.so
    #LoadModule auth_anon_module modules/mod_auth_anon.so
    #LoadModule auth_db_module modules/mod_auth_dbm.so
    LoadModule proxy_module modules/mod_proxy.so
    
  2. Restart OHS.

Error 404 - Not Found is Issued (OHS Side)

Typically, this error has the following format:

The requested URL <request-uri> was not found on this server

Most likely, the WebLogic redirect is not happening, and the request is attempting to grab an OHS resource not available.

To address this problem, verify that mod_weblogic is included in the file httpd.conf and that the WebLogic handler is set for the request pattern, as illustrated in the following fragment:

#httpd.conf
<IfModule mod_weblogic.c> 
 WebLogicHost <host>
  WebLogicPort yourWlsPortNumber
</IfModule>
 
<Location /request-uri-pattern>
 SetHandler weblogic-handler
</Location>

Error 404 - Not Found is Issued (Oracle WebLogic Server Side)

Typically, this error has the following format:

Error 404--Not Found

Cause

This message informs that the Oracle WebLogic Server is not able to find a resource.

Solution

To address the problem, check that the resource is indeed deployed on the server. For example, if the pattern is /private1/Hello, check that Hello is accessible on the server with private1 as root.

Oracle SSO Failure - Unable to process request

Problem

You receive a message stating:

Oracle SSO Failure - Unable to process request
Either the requested URL was not specified in terms of a fully-qualified host
name or Oracle HTTP Server single sign-on is incorrectly configured.
Please notify your administrator. 

Solution

Modify the Oracle HTTP Server httpd.conf file to include a port number in the ServerName and restart the Web server. For example:

From: ServerName host.domain.com

To: ServerName host.domain.com:port

OSSO Solution for Applications Deployed on a Stand-alone WebLogic Server

This chapter describes how to configure single sign-on (SSO) for applications that are deployed on Oracle Fusion Middleware Oracle WebLogic Server. However, details for applications that are deployed on a stand-alone Oracle WebLogic Server (one without Fusion Middleware) are provided here:

  • Oracle Fusion Middleware with OSSO: The required OSSO Identity Asserter (ossoiap.jar) is provided automatically when you install Oracle Fusion Middleware: Oracle Identity Management, Oracle SOA Suite, or Oracle WebCenter.


    Note:

    Oracle Fusion Middleware with OSSO enables you to use either the Oracle HTTP Server 10g or 11g Web server.

  • Stand-Alone Oracle WebLogic Server with OSSO: The required OSSO Identity Asserter (ossoiap.jar) must be acquired from the Oracle Web Tier, as described here.


    Note:

    Without Fusion Middleware, OSSO requires Oracle HTTP Server 11g.

Whether you use OSSO for Oracle Fusion Middleware applications or other applications, the Identity Asserter performs the same functions as those illustrated and described in "Using the OSSO Identity Asserter".

Included in the following are additional, optional, details that you can use to configure and test Single Logout for session invalidation and synchronization between the SSO cookie and the JSESSIONID cookie. Required files must be acquired from the Oracle Web Tier.

Task overview: Deploying and configuring the OSSO Identity Asserter for applications on a stand-alone WebLogic Server

  1. Install Oracle WebLogic Server 10.3.1+ and other required components as follows:

    1. Perform Step 1, a-d as described in the "Task overview: Deploying and configuring the OSSO Identity Asserter for applications on a stand-alone WebLogic Server".

    2. Skip Step 1e and instead deploy your application.

  2. Create a WebLogic security domain with the weblogin domain extension template that is supplied with Oracle WebLogic Server and can be used from $WLS_HOME/common/bin/config.sh.

  3. Configure mod_weblogic to forward requests to Oracle WebLogic Server, as explained in "Configuring mod_weblogic".

  4. Register and configure the module mod_osso with the 10g SSO Server as a partner application, as described in "New Users of the OSSO Identity Asserter".

    1. Perform steps described in "Registering Oracle HTTP Server mod_osso with OSSO Server 10.1.4".

    2. Perform steps described in "Configuring mod_osso to Protect Web Resources".

  5. Add Authentication Providers to the appropriate security domain as follows:

    1. Acquire the OSSO Identity Asserter (ossoiap.jar from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar  
      
    2. Copy ossoiap.jar into $WLS_HOME/wlserver_10.x/server/lib/mbeantype, then restart the Oracle WebLogic Server.

    3. Configure providers as described in "Adding Providers to a WebLogic Domain for OSSO".

  6. Configure the Oracle WebLogic Connection Filtering mechanism to create access control lists and accept requests from the hosts where Oracle HTTP Server and the front-end Web server are running, as explained in "Establishing Trust Between Oracle WebLogic Server and Other Entities".


    Note:

    Test the secured application to ensure that it is working with the default authenticator using the Oracle WebLogic Server host and port.

  7. Configure the application authentication method for the OSSO Identity Asserter (all web.xml files in the application EAR file must include CLIENT-CERT in the element auth-method), as explained in "Configuring the Application for the OSSO Identity Asserter".


    Note:

    Test the application with users authenticated by OSSO while accessing the application with the Oracle HTTP Server host and port.

  8. Optional: You can configure and test Single Logout [Session Invalidation and synchronization between the SSO cookie and JSESSIONID cookie] as follows:

    1. Acquire ssofilter.jar and configure Oracle WebLogic Server to use it as follows:

      1. Acquire ssofilter.jar from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.ssofilter_11.1.1/ssofilter.jar  
      

      2. Copy it to an appropriate directory in Oracle Middleware home: WLS_INSTALL/Oracle/Middleware/modules directory, for example.

      3. Add the absolute path of ssofilter.jar to the Oracle WebLogic Server classpath (by editing the setDomainEnv.sh script POST_CLASSPATH variable or CLASSPATH variable).

    2. Deploy system-filters.war as a system filter, as follows:

      1. Acquire system-filters.war from the Oracle Web Tier at:

      $ORACLE_INSTANCE/modules/oracle.jrf_11.1.1/system-filters.war 
       
      

      2. Copy system-filters.war to an appropriate directory in Oracle Middleware home: WLS_INSTALL/Oracle/Middleware/modules directory, for example.

      3. Deploy system-filters.war as an application library: From the WebLogic Administration Console, click Deployment, select New, and choose the location of file.

      4. Restart the Oracle WebLogic Server, if asked.

    3. Enable Logs to verify that the SSOFilter is working, as follows:

      1. From the WebLogic Administration Console, click Domain, Environment, Servers, AdminServer.

      2. Click the Logging tab.

      3. From the Advanced drop-down, select "Minimum Severity to Log" as "Debug".

      4. From the Advanced drop-down, "Message destinations", select LogFile: Severity Level as "Debug".

      5. Save changes and restart the Oracle WebLogic Server.

    4. Confirm that the SSOFilter is loaded as a system filter:

      1. Open the AdminServer.log file in DomainHome/Servers/AdminServer/log/AdminServer.log.

      2. Search for "SSOFilter" and confirm that you can see <Debug> messages, which indicate SSOFilter initialization nd confirm a filter load

    5. Test the filter functionality to confirm that the SSO and JSESSIONID cookie are cleaned up after user logout and that attempts to access the application after logout require another login.


      Note:

      You must have OSSO Identity Asserter configured in the WebLogic security domain, otherwise the filter will automatically disable during its initialization.

    6. Test logout with applications to confirm that the session is ends cleanly.

SSO Users Specified in "Users to Always Audit" Must Be Uppercase

When you specify SSO users in the Oracle HTTP Server audit configuration "Users to Always Audit" section, the SSO username must be specified in uppercase characters.

A comma-separated list of users can be specified to force the audit framework to audit events initiated by these users. Auditing occurs regardless of the audit level or filters that have been specified. This is true for all authentication types.

For more information, see "Managing Audit Policies" in the chapter "Configuring and Managing Auditing" in the Oracle Fusion Middleware Application Security Guide.

18.3.3 URL Rewriting and JSESSIONID

In some cases when an application resource (URL) is accessed and the JSESSIONID cookie is not found, WebLogic Server rewrites the URL by including the JSESSIONID as part of the URL. If the URL in question is protected, Oracle Access Manager and OSSO Web agents might have issues matching the re-written URL.

To avoid issues of a mismatch, you can append an asterisk, *, to the end of the protected resource specified in mod_osso.conf. For example, if the protected URL is:

/myapp/login

The location in the mod_osso entry would be:

<Location /myapp/login*>
valid user
AuthType OSSO
</Location>

18.3.4 About mod_osso, OSSO Cookies, and Directives

Mod_osso module provides communication between the SSO-enabled login server and the Oracle HTTP Server listener. The mod_osso module is controlled by editing the mod_osso.conf file:

This section provides the following information:

18.3.4.1 New OssoHTTPOnly Directive in mod_osso

A new configuration directive has been added to mod_osso to configure setting the HTTPOnly flag on OSSO cookies. The new Directive is: OssoHTTPOnly. Values are On (to enable) and Off (to disable) the flag. By default, the HTTPOnly flag is set to On; the directive is not set in the configuration.

This directive appends the HttpOnly flag to the OSSO cookies set in the browser. This purpose of this flag is to prevent cross-site scripting. Cookies that have this flag set are not accessible by javascript code or applets running on the browser. Cookies that have this flag set is only sent to the server that set the cookie for the particular domain across over http or https.

This is a per VirtualHost directive. It can only be set at the global scope or inside a VirtualHost section. The following example shows the new directive:

<VirtualHost *.7778> 
OssoConfigFile  conf/osso.conf
OssoHTTPOnly On
---
---
---
<Location /osso>
AuthType Osso
---
---
</Location> 

</VirtualHost> 

18.3.4.2 OssoSecureCookies Directive in mod_osso

In mod_osso 10g, the OssoSecureCookies directive is disabled by default. However, in mod_osso 11g, this behavior is enabled by default. In mod_osso 11g, to disable the OssoSecureCookies directive you must set OssoSecureCookies to Off in the corresponding configuration file. When mod_osso is enabled, the mod_osso.conf file is available at:

ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf

Set the OssoSecureCookies directive as follows:

OssoSecureCookies "Off"

18.3.4.3 Mod_osso Does Not Encode the Return URL

Mod_osso does not encode the return URL in the query when redirecting to the Oracle SSO Server for logout.

To fix this issue, the encoded URL must be passed. For example: response.setHeader("Osso-Return-Url", encoded-url)

18.3.4.4 mod_osso: "Page Not found" error After Default Installation

The following causes might result in a "Page Not Found" error when trying to display SSO page:

  • Multiple routing relationships with the same OHS in the absence of load balancer: This is not supported.

  • No routing relationship

Solutions: Multiple Routing Relationships

Locate and remove the extra routing relationship that is not related to this oc4j_im. Leave the routing relationship that is related to this oc4j_im.

  1. Use the following command to display all routing relationships in your environment:

    asctl:/imha/inst1/ohs_im>ls -a -l
    oc4j_im_ohs_im_routing_relationship -> /imha/inst12/oc4j_im 
    oc4j_im_ohs_im_routing_relationship_ -> /imha/inst11/oc4j_im 
    
  2. Remove the routing relationship that is not related to this specific oc4j_im using the following command with values for your environment. For example:

    asctl:/imha/inst1/ohs_im> rmrel(name='oc4j_im_ohs_im_routing_relationship_
    ',pt='/imha/inst11/oc4j_im')
    
  3. Stop and start both OHS Web server and oc4j_im.

  4. Confirm that the SSO page displays.

Solutions: No Routing Relationships

By default, the installer creates a routing relationship between each OHS and each oc4j_im. If there is no routing relationship between OHS and oc4j_im, you must create one.

  1. Use the following command to create a routing relationship using values for your environment:

    createRoutingRelationship(name='rr1',ut='/imha/inst1/ohs_im',pt='/imha/inst12/  
    @ oc4j_im') 
    
  2. Stop and start both OHS Web server and oc4j_im.

  3. Confirm that the SSO page displays.

18.3.5 About Using IPv6

Oracle Fusion Middleware supports Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6.) Among other features, IPv6 supports a larger address space (128 bits) than IPv4 (32 bits), providing an exponential increase in the number of computers that can be addressable on the Web.


See Also:

Oracle Fusion Middleware Administrator's Guide for details about using IPv6 with the Oracle Single Sign-on Server.

PK1PKfp@OEBPS/wlstcmds.htm OPSS Scripts

I OPSS Scripts

An OPSS script is either a WLST script, in the context of the Oracle WebLogic Server, or a WASAdmin script, in the context of the WebSphere Application Server. The scripts listed in this chapter apply to both platforms: WebLogic Application Server and WebSphere Application Server.

For OPSS scripts details specific to WebSphere Application Server, see Oracle Fusion Middleware Third-Party Application Server Guide.

The OPSS security-related scripts are described in the following sections:

I.1 Policy-Related Scripts

For details on the following scripts, see Section 9.3, "Managing Application Policies with OPSS Scripts."

I.2 Credential-Related Scripts

For details on the following scripts, see Section 10.5, "Managing Credentials with OPSS Scripts."

I.3 Other Security Scripts

I.4 Audit Scripts

For the description of audit-related scripts, see Section C.4, "WLST Commands for Auditing."

PKiPKfp@OEBPS/apupgrade.htm Upgrading Security Data

G Upgrading Security Data

This appendix describes several procedures to update security data. Specifically, it describes how to upgrade security data from a major release (10.1.3.x) to a major release (11.1.1), and how to upgrade data from a minor release (11g OPSS PS1, PS2, PS3 or PS4) to 11g OPSS PS5, in the following sections:


If upgrading from 11gR1 to 11gR1 PS1:

For details about this upgrade combination, see section Special Instructions for Oracle Fusion Middleware 11g Release 1 (11.1.1.1.0) in Oracle Fusion Middleware Installation Planning Guide.

For an overview and details about Identity Management upgrade, see Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management.

G.1 Upgrading with upgradeSecurityStore

The OPSS script upgradeSecurityStore is used only to upgrade application security data from a previous major release (such as 10.1.1.3) to more recent one (such as 11.1.1.1). To upgrade between minor 11g releases, use upgradeOpss as described in section Upgrading Policies with upgradeOpss.

If the target of the upgrading is an LDAP-based repository, then some setting up before running the script is required, as described in Section 8.2.2, "Prerequisites to Using an LDAP-Based Security Store."

The script is offline, that is, it does not require a connection to a running server to operate, and can be run in interactive mode or in script mode, on WebLogic, and in interactive mode only, on WebSphere. In interactive mode, you enter the script at a command-line prompt and view the response immediately after. In script mode, you write scripts in a text file and run it without requiring input, much like the directives in a shell script.

For platform-specific requirements to run an OPSS script, see Important Note.

Script and Interactive Modes Syntaxes

The script syntax varies depending on the type of store being upgraded. Optional arguments are enclosed in square brackets; arguments in script mode syntax are written in separate lines for clarity of exposition.

To upgrade 10.1.3.x XML identity data to 11g Release 1 (11.1.1) XML identity data, use either of the following syntaxes:

updateSecurityStore -type xmlIdStore
                    -jpsConfigFile jpsConfigFileLocation
                    -srcJaznDataFile srcJazn
                    -srcRealm jaznRealm
                    [-dst dstJpsContext]

updateSecurityStore(type="xmlIdStore", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", srcRealm="jaznRealm", [dst="dstJpsContext"])
                     

To upgrade a 10.1.3.x XML policy data to 11g Release 1 (11.1.1) XML policy data, use either of the following syntaxes:

updateSecurityStore -type xmlPolicyStore
                    -jpsConfigFile jpsConfigFileLocation
                    -srcJaznDataFile srcJazn
                    [-dst dstJpsContext]

updateSecurityStore(type="xmlPolicyStore", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", [dst="dstJpsContext"])
                     

To upgrade a 10.1.3.x Oracle Internet DirectoryLDAP-based policy data to 11g Release 1 (11.1.1) XML policy data, use either of the following syntaxes:

updateSecurityStore -type oidPolicyStore
                    -jpsConfigFile jpsConfigFileLocation
                    -srcJaznConfigFile srcJazn
                    [-dst dstJpsContext]

updateSecurityStore(type="oidPolicyStore", jpsConfigFile="jpsConfigFileLocation", srcJaznConfigFile="srcJazn", [dst="dstJpsContext"])
                     

To upgrade file-based application policies from release 11.1.1.1.0 to release 11.1.1.2.0, use either of the following syntaxes:

updateSecurityStore -type xmlAppPolicies
                    -srcApp applicationStripeName
                    -jpsConfigFile jpsConfigFileLocation
                    -srcJaznDataFile srcJazn
                    -dstJaznDataFile dstJazn
                    -resourceTypeFile resTypeJazn

updateSecurityStore(type="xmlAppPolicies", srcApp="applicationStripeName", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", dstJaznDataFile="dstJazn", srcJaznDataFile="resTypeJazn")
                     

To upgrade 11.1.1.1.0 application policies to 11.1.1.2.0 format, use either of the following syntaxes:

updateSecurityStore -type appPolicies
                    -srcApp applicationStripeName
                    -jpsConfigFile jpsConfigFileLocation
                    -dst dstContext
                    [-resourceTypeFile resTypeJazn]

updateSecurityStore(type="appPolicies", srcApp="applicationStripeName", jpsConfigFile="jpsConfigFileLocation", dst="dstContext" [, resourceTypeFile="resTypeJazn"])
                     

This upgrade works in-place and involves the creation of specified resource types and resources corresponding to permissions in the grants.

Once the run completes, the policy store pointed to by the context passed in dst in the configuration file passed in jpsConfigFile has new resource types and new resources defined for application passed in srcApp. The resource types are read from the file specified in resourceTypeFile and resources are created corresponding to permissions in the application grants.

The meaning of the arguments is as follows:

  • type specifies the kind of security data being upgraded. The only valid values are xmlIdStore, xmlPolicyStore, oidPolicyStore, xmlCredStore, xmlAppPolicies, and appPolicies.

  • jpsConfigFile specifies the location of a configuration file jps-config.xml relative to the directory where the script is run. The target store of the upgrading is read from the context specified with the argument dst.

    In case the type is xmlAppPolicies, the configuration file is not used to point to neither source nor destination, but to configure the audit service only. Note that the location must be passed even when the audit service is not specified in the jps-config.xml file.

  • srcJaznDataFile specifies the location of a 10.1.3.x jazn-data.xml file relative to the directory where the script is run. This argument is required if the specified type is xmlIdStore, xmlPolicyStore, or xmlCredStore.

    In case the specified type is xmlAppPolicies, it specifies the location of the application 11.1.1.1.0 jazn-data.xml file, a file that does not include resource type specifications.

  • srcJaznConfigFile specifies the location of a 10.1.3.x jazn configuration file relative to the directory where the script is run. This argument is required if the specified type is oidPolicyStore.

  • users specifies a comma-delimited list of users each formatted as realmName/userName. This argument is required if the specified type is xmlCredStore.

  • srcRealm specifies the name of a realm in the file passed to the argument srcJaznDataFile that identifies the identities to be migrated. This argument is required if the specified type is xmlIdStore.

  • dst specifies the name of a jpsContext in the file passed to the argument jpsConfigFile where the destination store is configured. Optional. If unspecified, it defaults to the default jpsContext.

  • srcApp specifies the application stripe. It should match the application name present in the files srcJaznDataFile and resourceTypeFile. A stripe with this name is created in the file dstJaznDataFile.

  • dstJaznDataFile specifies the location of the application 11.1.1.2.0 jazn-data.xml file. This file includes resource type and resource instance specifications and is the replacement for the original jazn-data.xml specified in srcJaznDataFile.

  • resourceTypeFile specifies the location of the 11.1.1.2.0 jazn-data.xml file which includes resource type specifications.

  • dst specifies the destination context that points to the policy store to update.

G.1.1 Examples of Use

The following sections contain examples that illustrate the use of the script upgradeSecurityStore in different scenarios:

G.1.1.1 Example 1 - Upgrading Identities

The following invocation illustrates the migration of 10.1.3 file-based identities to an 11g Release 1 (11.1.1) file-based identity store:

upgradeSecurityStore -type xmlIdStore 
                     -jpsConfigFile jps-config-idstore.xml
                     -srcJaznDataFile jazn-data.xml
                     -srcRealm jazn.com

This use of the script assumes that: (a) the files jps-config-idstore.xml and jazn-data.xml are located in the directory where the script is run; (b) the default jpsContext in the file jps-config-idstore.xml references the target identity store; and (c) the file jazn-data.xml contains a realm named jazn.com.

Here are the relevant excerpts of the two files involved in the use sample above:

<!-- excerpt from file jps-config-idstore.xml -->  
<serviceProviders>
   <serviceProvider name="R11idstore" class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider" type="IDENTITY_STORE">
     <description>11g XML-based IdStore</description>
   </serviceProvider>
</serviceProviders>
...
<serviceInstances>
  <serviceInstance name="idstore.xml1" provider="R11idstore" location="./jazn-data-11.xml">
    <property name="subscriber.name" value="jazn.com"/>
    <property name="jps.xml.idstore.pwd.encoding" value="OBFUSCATE"/>
  </serviceInstance>
</serviceInstances> 
...
<jpsContexts default="default">
   <jpsContext name="default">
      <serviceInstanceRef ref="idstore.xml1" />
   </jpsContext>
</jpsContexts>
<!-- excerpt from jazn-data.xml -->
<jazn-realm>
          <realm>
                <name>jazn.com</name>
                    <users> ... </users>
    <roles> ... </roles>
  </realm>
</jazn-realm>

Thus, the sample invocation above migrates every user in the element <users>, to the XML identity store R11idStore.

G.1.1.2 Example 2 - Upgrading to File-Based Policies

The following invocation illustrates the migration of a 10.1.3 file-based policy store to an 11g Release 1 (11.1.1) policy store:

upgradeSecurityStore -type xmlPolicyStore 
                     -jpsConfigFile jps-config.xml
                     -srcJaznDataFile jazn-data.xml
                     -dst destContext

This use of the script assumes that: the files jps-config.xml and jazn-data.xml are located in the directory where the script is run; and the file jps-config.xml contains a jpsContext named destContext.

Here are the relevant excerpts of the two files involved in the use sample above:

<!-- excerpt from file jps-config.xml -->
<serviceProviders>
  <serviceProvider type="POLICY_STORE" name="policystore.xml.provider" class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider">
  <description>R11 XML-based PolicyStore Provider</description>
        </serviceProvider>
</serviceProviders>
...
<serviceInstances>
  <serviceInstance name="policystore1.xml" provider="policystore.xml.provider">
  <property name="R11PolStore" value="jazn-data1.xml"/>
</serviceInstance>
...
<jpsContexts default="default1">
   <jpsContext name="default1"> ... </jpsContext>
   <jpsContext name="destContext">
       ...
       <serviceInstanceRef ref="policystore1.xml"/>
   </jpsContext>
</jpsContexts>
<!-- excerpt from jazn-data.xml -->
<jazn-realm>
          <realm>
                ...
    <roles> ... </roles>
  </realm>
</jazn-realm>
...
<jazn-policy> ... </jazn-policy>

Thus, the sample invocation above migrates every role in the element <roles> and every policy in the element <jazn-policy> to the XML policy store R11PolStore.

G.1.1.3 Example 3 - Upgrading to Oracle Internet Directory LDAP-Based Policies

The following invocation illustrates the upgrading of a 10.1.4 Oracle Internet Directory LDAP-based policy store to an 11g Release 1 (11.1.1) Oracle Internet Directory LDAP-based policy store:

upgradeSecurityStore -type oidPolicyStore 
                     -jpsConfigFile jps-config.xml
                     -srcJaznConfigFile jazn.xml
                     -dst destContext

The assumptions about the location of the two XML files involved in this example are similar to those in Example 2. In addition, it is assumed that (a) the file jps-config.xml contains the jpsContext destContext that points to the target Oracle Internet Directory LDAP-based policy store; and (b) the file jazn.xml describes the location of the Oracle Internet Directory LDAP server from where the policies are migrated.

Here is the relevant excerpt from the file jazn.xml:

<jazn provider="LDAP" location="ldap://myCompany.com:3843">
   <property name="ldap.user" value="cn=orcladmin"/>
   <property name="ldap.password" value="!welcome1"/>
   <property name="ldap.protocol" value="no-ssl"/>
   <property name="ldap.cache.policy.enable" value="false"/>
   <property name="ldap.initctx" value="com.sun.jndi.ldap.LdapCtxFactory"/>
</jazn>

G.1.1.4 Example 4 - Upgrading File-Based Policies to Use the Resource Catalog

The following invocation upgrades an application 11.1.1.1.0 file-based policy store to an application 11.1.1.2.0 file-based policy store.

updateSecurityStore -type xmlAppPolicies
                    -srcApp PolicyServlet1
                    -jpsConfigFile ./folder/jps-config.xml
                    -srcJaznDataFile ./11.1.1.1.0/jazn-data.xml
                    -dstJaznDataFile ./11.1.1.2.0/final-jazn-data.xml
                    -resourceTypeFile ./resCat/res-jazn-data.xml
 

The point of this upgrade is that the original 11.1.1.1.0 file does not use resource catalog elements, but the resulting 11.1.1.2.0 file does use resource type and resource instance elements.

The script basically takes the original application configuration file, along with another file specifying resource type elements, and it produces a new application configuration file that contains policies as in the original file, but modified to use resource catalog specifications.

The original and the new application configuration files provide identical behavior to the application.

The above invocation assumes that:

  • The source file ./11.1.1.1.0/jazn-data.xml contains policies for the application PolicyServlet1.

  • The resource type file ./resCat/res-jazn-data.xml contains resource type specifications for the application PolicyServlet1.

  • The configuration file ./folder/jps-config.xml is any valid configuration file that may or may not use an audit service instance. In any case, it must be specified.

The following samples illustrate the relevant portions of three data files: the input source jazn-data.xml and resource res-jazn-data.xml, and the output final-jazn-data.xml.

Input Source File jazn-data.xml

<policy-store>
  <applications>
    <application>
      <name>PolicyServlet1</name>
      <app-roles>
        <app-role>
          <name>myAppRole2</name>
          <display-name>application role myAppRole</display-name>
          <members>
            <member>
              <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
              <name>myAppRole</name>
            </member>
          </members>
        </app-role>
        <app-role>
          <name>myAppRole</name>
          <display-name>application role myAppRole</display-name>
          <members>
            <member>
              <class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
              <name>developers</name>
            </member>
          </members>
        </app-role>
        <app-role>
          <name>testrole_DATA</name>
          <display-name>application role test</display-name>
          <members>
            <member>
              <class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
            <name>test-entrole</name>
          </member>
        </members>
      </app-role>
      <app-role>
        <name>myAppRole_PRIV</name>
        <display-name>application role private</display-name>
        <description>app role private description</description>
        <members>
          <member>
            <class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
            <name>developers</name>
          </member>
          <member>
            <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
            <name>myAppRole</name>
          </member>
        </members>
      </app-role>
    </app-roles>
    <jazn-policy>
      <grant>
        <grantee>
          <principals>
            <principal>
              <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
              <name>myAppRole_PRIV</name>
            </principal>
          </principals>
        </grantee>
        <permissions>
          <permission>
            <class>oracle.security.jps.JpsPermission</class>
            <name>getClassLoader</name>
          </permission>
          <permission>
            <class>
oracle.adf.share.security.authorization.RegionPermission</class>
            <name>dummyName</name>
            <actions>view,edit</actions>
          </permission>
        </permissions>
      </grant>
      <grant>
        <grantee>
          <principals>
            <principal>
              <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
              <name>myAppRole</name>
            </principal>
          </principals>
        </grantee>
        <permissions>
          <permission>
            <class>java.lang.XYZPermission</class>
            <name>newxyz</name>
          </permission>
        </permissions>
      </grant>
      <grant>
        <grantee>
          <principals>
            <principal>
              <class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
              <name>test-entrole</name>
            </principal>
          </principals>
        </grantee>
        <permissions>
          <permission>
            <class>oracle.security.jps.JpsPermission</class>
            <name>newxy</name>
            <actions>view,edit</actions>
          </permission>
        </permissions>
      </grant>
    </jazn-policy>
  </application>
 </applications>
</policy-store>

Input Resource File res-jazn-data.xml

<jazn-data>
  <jazn-realm default="jazn.com">
  </jazn-realm>
  <policy-store>
    <applications>
      <application>
        <name>PolicyServlet1</name>
        <resource-types>
          <resource-type>
            <name>FileResourceType</name>
            <display-name>File Access</display-name>
            <description>Resource Type Modelling File Access</description>
            <provider-name>provider</provider-name>
            <matcher-class>oracle.security.jps.JpsPermission</matcher-class>
            <actions-delimiter>,</actions-delimiter>
            <actions>delete,write,read</actions>
          </resource-type>
        </resource-types>
        <jazn-policy>
        </jazn-policy>
      </application>
    </applications>
  </policy-store>
  <jazn-policy>
  </jazn-policy>
</jazn-data>

Output Data File final-jazn-data.xml

<jazn-data>
  <jazn-realm>
  </jazn-realm>
  <policy-store>
    <applications>
      <application>
        <name>PolicyServlet1</name>
        <app-roles>
          <app-role>
            <name>myAppRole2</name>
            <display-name>application role myAppRole</display-name>
            <guid>4341CC10EAFB11DE9F7F17D892026AF8</guid>
            <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
            <members>
              <member>
                <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
                <name>myAppRole</name>
                <guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
              </member>
            </members>
          </app-role>
          <app-role>
            <name>myAppRole</name>
            <display-name>application role myAppRole</display-name>
            <guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
            <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
            <members>
              <member>
                <class>weblogic.security.principal.WLSGroupImpl</class>
                <name>developers</name>
              </member>
            </members>
          </app-role>
          <app-role>
            <name>testrole_DATA</name>
            <display-name>application role test role</display-name>
            <guid>4342B670EAFB11DE9F7F17D892026AF8</guid>
            <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
            <members>
              <member>
                <class>weblogic.security.principal.WLSGroupImpl</class>
                <name>test-entrole</name>
              </member>
            </members>
          </app-role>
          <app-role>
            <name>myAppRole_PRIV</name>
            <display-name>application role private</display-name>
            <description>app role private description</description>
            <guid>4342B671EAFB11DE9F7F17D892026AF8</guid>
            <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
            <members>
              <member>
                <class>
weblogic.security.principal.WLSGroupImpl</class>
                <name>developers</name>
              </member>
              <member>
                <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
                <name>myAppRole</name>
                <guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
              </member>
            </members>
          </app-role>
        </app-roles>
        <resource-types>
          <resource-type>
            <name>FileResourceType</name>
            <display-name>File Access</display-name>
            <description>Resource Type Modelling File Access</description>
            <provider-name>provider</provider-name>
            <matcher-class>oracle.security.jps.JpsPermission</matcher-class>
            <actions-delimiter>,</actions-delimiter>
            <actions>delete,write,read</actions>
          </resource-type>
        </resource-types>
        <resources>
          <resource>
            <name>getClassLoader</name>
            <type-name-ref>FileResourceType</type-name-ref>
          </resource>
          <resource>
            <name>newxy</name>
            <type-name-ref>FileResourceType</type-name-ref>
          </resource>
        </resources>
        <jazn-policy>
          <grant>
            <grantee>
              <principals>
                <principal>
                  <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
                  <name>myAppRole_PRIV</name>
                  <guid>4342B671EAFB11DE9F7F17D892026AF8</guid>
                </principal>
              </principals>
            </grantee>
            <permissions>
              <permission>
                <class>oracle.security.jps.JpsPermission</class>
                <name>getClassLoader</name>
              </permission>
              <permission>
                <class>
oracle.adf.share.security.authorization.RegionPermission</class>
                <name>dummyName</name>
                <actions>view,edit</actions>
              </permission>
            </permissions>
            <permission-set-refs>
            </permission-set-refs>
          </grant>
          <grant>
            <grantee>
              <principals>
                <principal>
                  <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
                  <name>myAppRole</name>
                  <guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
                </principal>
              </principals>
            </grantee>
            <permissions>
              <permission>
                <class>java.lang.XYZPermission</class>
                <name>newxyz</name>
              </permission>
            </permissions>
            &lBt;permission-set-refs>
            </permission-set-refs>
          </grant>
          <grant>
            <grantee>
              <principals>
                <principal>
                  <class>
weblogic.security.principal.WLSGroupImpl</class>
                  <name>test-entrole</name>
                </principal>
              </principals>
            </grantee>
            <permissions>
              <permission>
                <class>oracle.security.jps.JpsPermission</class>
                <name>newxy</name>
                <actions></actions>
              </permission>
            </permissions>
            <permission-set-refs>
            </permission-set-refs>
          </grant>
        </jazn-policy>
      </application>
    </applications>
  </policy-store>
  <jazn-policy>
  </jazn-policy>
</jazn-data>

G.2 Upgrading Policies with upgradeOpss

upgradeOpss is an offline script that updates PS1, PS2, PS3 or PS4 configurations and stores to a PS5 configuration and store.

The store to be upgraded can be file-, LDAP-, or DB-based and possibly be shared by several WebLogic domains, and the script upgrades system policies, application policies, and the file jps-config.xml.

The OPSS binaries and the target policy store must have compatible versions; for details, see Section L.21, "Incompatible Versions of Binaries and Policy Store."


Important Notes:

upgradeOpss must be run on the system that hosts the administration server instance so that when the server comes up, the upgraded data is pushed to all managed servers in the cluster.

Before using it, make sure that you backup the store to be upgraded. In case of a LDAP store, backup all data under the root node of the store (which is specified as a property of the store in the configuration file). In case of an upgrade failure, restore that node entirely. For details about backing up, see the documentation for your specific LDAP store.


To upgrade from PS1, PS2, PS3 or PS4 to PS5, proceed as follows:

  1. Stop the application server.

  2. Install new binaries.

  3. In case of upgrading a DB-based store, use Oracle Fusion Middleware Patch Set Assistant to upgrade the DB schema as follows:

    1. Navigate to the OPSS Schema page.

    2. Enter data for Connect String, DBA User Name and Password, and Schema User Name and Password and then click Next.

  4. Run upgradeOpss as described in section Command Syntax.

  5. Restart the application server.

Note the following points:

G.2.1 Command Syntax

To upgrade a file-, LDAP-, or DB-based store, use the syntax below; note that the connection arguments are not required in case of a file-based store; are optional in case of an LDAP-based store; and are required in case of a DB-based store:

upgradeOpss(jpsConfig="<full path to the old version jps config file>",
            jaznData="<full path to the new version OOTB JAZN data file>",
            [auditStore="<full path to the OOTB audit-store.xml file>"],
            [jdbcDriver="<jdbc driver>", 
url="<jdbc-ldap url>", user="<jdbc-ldap user>", password="<jdbc-ldap password>"],

The meaning of the arguments is as follows:

  • jpsConfig specifies the full path to the location of the PS1, PS2, PS3 or PS4 jps-config.xml configuration file, which the scripts backs up in the same directory as a file with the suffix .bak appended to the its name; required.

  • jaznData specifies the full path to the location of the PS5 out-of-the-box system-jazn-data.xml file; required.

  • auditStore specifies the full path to the location of the PS5 out-of-the-box audit-store.xml file; optional; if unspecified, defaults to the file audit_store.xml.

  • jdbcDriver specifies the JDBC driver to the store; optional in case of LDAP-based store; required in case of DB-based store.

  • url specifies the JDBC URL or LDAP URL in the format driverType:host:port:sid; required in both DB- or LDAP-based store; if not passed, it is read from the configuration file.

  • user specifies the JDBC user name or LDAP bind name; optional in case of LDAP-based store; required in case of DB-based store; if not passed, it is read from the configuration file. In case of LDAP-based store, the user performing the upgrade must have read and write privileges to the schema, the root node, and all nodes under cn=OPSS,cn=OracleSchemaVersion; in case of a DB-based store, perform the upgrade as the OPSS DB schema user.

  • password specifies the password of the passed user; that is, the JDBC password, in case of a DB-based store, or the JDBC bind password, in case of a LDAP-based store; optional in case of LDAP-based store; required in case of DB-based store; if not passed, it is read from the configuration file.

PK?ĘǝPKfp@ OEBPS/loe.htm y List of Examples

List of Examples

PK @ PKfp@OEBPS/apjpscfg.htm OPSS Configuration File Reference

A OPSS Configuration File Reference

This appendix describes the element hierarchy and attributes in the file that configures OPSS services. By default, this file is named jps-config.xml (for Java EE applications) or jps-config-jse.xml (for Java SE applications) and is located in the directory $DOMAIN_HOME/config/fmwconfig.

For Java SE applications, an alternative location can be specified using the system property oracle.security.jps.config.

The configuration file is used to configure the policy, credential, and identity stores, the login modules, and the audit service. For a complete example of a configuration file see Section 21.4.9, "Example of Configuration File jps-config.xml."

To configure services programmatically, see Section E.2, "Configuring OPSS Services with MBeans."

This appendix includes the following sections:

A.1 Top- and Second-Level Element Hierarchy

The top element in the file jps-config.xml is <jpsConfig>. It contains the following second-level elements:

  • <property>

  • <propertySets>

  • <extendedProperty>

  • <serviceProviders>

  • <serviceInstances>

  • <jpsContexts>

Table A-1 describes the function of these elements. The annotations between curly braces{} indicate the number of occurrences the element is allowed. For example, {0 or more} indicates that the element can occur 0 or more times; {1} indicates that the element must occur once.

These elements are not application-specific configurations: all items in the configuration file pertain to an entire domain and apply to all managed servers and applications deployed in the domain.

Table A-1 First- and Second-Level Elements in jps-config.xml

ElementsDescription
<jpsConfig> {1}

Defines the top-level element in the configuration file.

    <property> {0 or more}

Defines names and values of properties. It can also appear elsewhere in the hierarchy, such as under the elements <propertySet>, <serviceProvider>, and <serviceInstance>.

    <propertySets> {0 or 1}
        <propertySet> {1 or more}
            <property> {1 or more}

Groups one or more <propertySet> elements so that they can referenced as a group.

    <extendedProperty> {0 or more}
        <name> {1}
        <values> {1}
            <value> {1 or more}

Defines a property that has multiple values. It can also appear elsewhere in the hierarchy, such as under the elements extendedProperty and serviceInstance.

    <extendedPropertySets> {0 or 1}
        <extendedPropertySet> {1 or more}
            <extendedProperty> {1 or more}
                <name> {1}
                <values> {1}
                    <value> {1 or more}

Groups one or more <extendedPropertySet> elements so that they can referenced a group.

    <serviceProviders> {0 or 1}
        <serviceProvider> {1 or more}
            <description> {0 or 1}
            <property> {0 or more}

Groups one or more <serviceProvider> elements, each of which defines an implementation of an OPSS service, such as a policy store provider, a credential store provider, or a login module.

    <serviceInstances> {0 or 1}
        <serviceInstance> {1 or more}
            <description> {0 or 1}
            <property> {0 or more}
            <propertySetRef> {0 or more}
            <extendedProperty> {0 or more}
                <name> {1}
                <values> {1}
                    <value> {1 or more}
            <extendedPropertySetRef> {0 or more}

Groups one or more <serviceInstance> elements, each of which configures and specifies property values for a service provider defined in a <serviceProvider> element.

    <jpsContexts> {1}
        <jpsContext> {1 or more}
            <serviceInstanceRef> {1 or more}

Groups one or more <jpsContext> elements, each of which is a collection of service instances that an application can use.


A.2 Lower-Level Elements

This section describes, in alphabetical order, the complete set of elements that can occur in under the second-level elements described in the Top- and Second-Level Element Hierarchy.


<description>

This element describes the corresponding entity (a service instance or service provider).

Parent Elements

<serviceInstance> or <serviceProvider>

Child Element

None.

Occurrence

<description> can be a child of <serviceInstance> or <serviceProvider>.

Example

The following example sets a description for a service provider.

<serviceProvider ... >
   <description>XML-based IdStore Provider</description>
   ...
</serviceProvider>

 


<extendedProperty>

This element defines an extended property in the following scenarios:

An extended property typically includes multiple values. Use a <value> element to specify each value. Several LDAP identity store properties are in this category, such as the specification of the following values:

Parent Elements

<extendedPropertySet>, <jpsConfig>, or <serviceInstance>

Child Elements

<name> or <values>

Occurrence

<extendedProperty> can be a child of <extendedPropertySet>, <jpsConfig>, or <serviceInstance>.

Example

The following example sets a single value:

<extendedProperty>
   <name>user.search.bases</name>
   <values>
      <value>cn=users,dc=us,dc=oracle,dc=com</value>
   </values>
</extendedProperty>

<extendedPropertySet>

This element defines a set of extended properties. The extended property set can then be referenced by an <extendedPropertySetRef> element to specify the given properties as part of the configuration of a service instance.

Attributes

NameDescription
name              Designates a name for the extended property set. No two <extendedPropertySet> elements may have the same name attribute setting within a configuration file.

Values: string

Default: n/a (required)


Parent Element

<extendedPropertySets>

Child Element

<extendedProperty>

Occurrence

Required within <extendedPropertySets>, one or more:

<extendedPropertySets> {0 or 1}
    <extendedPropertySet> {1 or more}
        <extendedProperty> {1 or more}
            <name> {1}
            <values> {1}
                <value> {1 or more}

<extendedPropertySetRef>

This element configures a service instance by referring to an extended property set defined elsewhere in the file.

Attributes

NameDescription
ref               Refers to an extended property set whose extended properties are used for the service instance defined in the <serviceInstance> parent element. The ref value of <extendedPropertySetRef> must match the name value of an <extendedPropertySet> element.

Values: string

Default: n/a (required)


Parent Element

<serviceInstance>

Child Element

None.

Occurrence

Optional, zero or more.

<serviceInstances> {0 or 1}
    <serviceInstance> {1 or more}
        <description> {0 or 1}
        <property> {0 or more}
        <propertySetRef> {0 or more}
        <extendedProperty> {0 or more}
            <name> {1}
            <values> {1}
                <value> {1 or more}
        <extendedPropertySetRef> {0 or more}

<extendedPropertySets>

This element specifies a set of properties.

Parent Element

<jpsConfig>

Child Element

<extendedPropertySet>

Occurrence

Optional, zero or one.

<jpsConfig>
    <extendedPropertySets> {0 or 1}
        <extendedPropertySet> {1 or more}
            <extendedProperty> {1 or more}
                <name> {1}
                <values> {1}
                    <value> {1 or more}

<jpsConfig>

This is the root element of a configuration file.

Parent Element

None.

Child Elements

<extendedProperty>, <extendedPropertySets>, <jpsContexts>, <property>, <propertySets>, <serviceInstances>, or <serviceProviders>

Occurrence

Required, one only.

Example

<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
    schema-major-version="11" schema-minor-version="1">
...
</jpsConfig>

 


<jpsContext>

This element declares an OPSS context, a collection of service instances common to a domain, either by referring to a set of service instances that comprise the context (typical usage), or by referring to another context. Each <jspContext> in a configuration file must have a distinct name.

Attributes

NameDescription
nameDesignates a name for the OPSS context. Each context must have a unique name.

Values: string

Default: n/a (required)


Parent Element

<jpsContexts>

Child Element

<serviceInstanceRef>

Occurrence

There must be at least one <jpsContext> element under <jpsContexts>. A <jpsContext> element contains the <serviceInstanceRef> element.

<jpsContexts> {1}
    <jpsContext> {1 or more}
        <serviceInstanceRef> {1 or more}

Example

The following example illustrates the definition of two contexts; the first one, named default, is the default context (specified by the attribute default in <jpsContexts>), and it references several service instances by name.

The second one, named anonymous, is used for unauthenticated users, and it references the anonymous and anonymous.loginmodule service instances.

<serviceInstances>
...
   <serviceInstance provider="credstoressp" name="credstore">
      <description>File Based Default Credential Store Service Instance</description>
      <property name="location" value="${oracle.instance}/config/JpsDataStore/JpsSystemStore"/>
   </serviceInstance>
...
   <serviceInstance provider="anonymous.provider" name="anonymous">
      <property value="anonymous" name="anonymous.user.name"/>
      <property value="anonymous-role" name="anonymous.role.name"/>
   </serviceInstance>
...
   <serviceInstance provider="jaas.login.provider" name="anonymous.loginmodule">
      <description>Anonymous Login Module</description>
      <property value="oracle.security.jps.internal.jaas.module.anonymous.AnonymousLoginModule"
                name="loginModuleClassName"/>
      <property value="REQUIRED"
                name="jaas.login.controlFlag"/>
   </serviceInstance>
...
</serviceInstances>
...
<jpsContexts default="default">
...
   <jpsContext name="default">
      <!-- This is the default JPS context. All the mandatory services and Login Modules must be
           configured in this default context -->
      <serviceInstanceRef ref="credstore"/>
      <serviceInstanceRef ref="idstore.xml"/>
      <serviceInstanceRef ref="policystore.xml"/>
      <serviceInstanceRef ref="idstore.loginmodule"/>
      <serviceInstanceRef ref="idm"/>
   </jpsContext>
   <jpsContext name="anonymous">
       <serviceInstanceRef ref="anonymous"/>
       <serviceInstanceRef ref="anonymous.loginmodule"/>
   </jpsContext>
...
</jpsContexts>

 


<jpsContexts>

This element specifies a set of contexts.

Attributes

NameDescription
default         Specifies the context that is used by an application if none is specified. The default value of the <jpsContexts> element must match the name of a <jpsContext> child element.

Values: string

Default: n/a (required)

Note: The default context must configure all mandatory services and login modules.


Parent Element

<jpsConfig>

Child Element

<jpsContext>

Occurrence

Required, one only.

<jpsConfig>
    <jpsContexts> {1}
        <jpsContext> {1 or more}

Example

See <jpsContext> for an example.

 


<name>

This element specifies the name of an extended property.

Parent Element

<extendedProperty>

Child Element

None

Occurrence

Required, one only.

<extendedProperty> {0 or more}
    <name> {1}
    <values> {1}
        <value> {1 or more}

Example

See <extendedProperty> for an example.

 


<property>

This element defines a property in the following scenarios:

For a list of properties, see Appendix F, "OPSS System and Configuration Properties".

Attributes

NameDescription
name  Specifies the name of the property being set.

Values: string

Default: n/a (required)

valueSpecifies the value of the property being set.

Values: string

Default: n/a (required)


Parent Elements

<jpsConfig>, <propertySet>, <serviceInstance>, or <serviceProvider>

Child Element

None.

Occurrence

Under a<propertySet>, it is required, one or more; otherwise, it is optional, zero or more.

Example

The following example illustrates a property to disable JAAS mode for authorization:

<jpsConfig ... >
   ...
   <property name="oracle.security.jps.jaas.mode" value="off"/>
   ...
</jpsConfig>

For additional examples, see <propertySet> and <serviceInstance>.

 


<propertySet>

This element defines a set of properties. Each property set has a name so that it can be referenced by a <propertySetRef> element to include the properties as part of the configuration of a service instance.

Attributes

NameDescription
name              Designates a name for the property set. No two <propertySet> elements may have the same name within a jps-config.xml file.

Values: string

Default: n/a (required)


Parent Element

<propertySets>

Child Element

<property>

Occurrence

Required within a<propertySets>, one or more

<propertySets> {0 or 1}
    <propertySet> {1 or more}
        <property> {1 or more}

Example

<propertySets>
...
   <!-- For property that points to valid Access SDK installation directory -->
   <propertySet name="access.sdk.properties">
      <property name="access.sdk.install.path" value="$ACCESS_SDK_HOME"/>
   </propertySet>
...
</propertySets>

<serviceInstances>
...
   <serviceInstance provider="jaas.login.provider" name="oam.loginmodule">
      <description>Oracle Access Manager Login Module</description>
      <property
          value="oracle.security.jps.internal.jaas.module.oam.OAMLoginModule"
          name="loginModuleClassName"/>
      <property value="REQUIRED" name="jaas.login.controlFlag"/>
      <propertySetRef ref="access.sdk.properties"/>
   </serviceInstance>
...
</serviceInstances>

<propertySetRef>

This element configures a service instance by referring to a property set defined elsewhere in the file.

Attributes

NameDescription
ref              Refers to a property set whose properties are used by the service instance defined in the <serviceInstance> parent element. The ref value of a <propertySetRef> element must match the name of a <propertySet> element.

Values: string

Default: n/a (required)


Parent Element

<serviceInstance>

Child Element

None.

Occurrence

Optional, zero or more.

<serviceInstances> {0 or 1}
    <serviceInstance> {1 or more}
        <description> {0 or 1}
        <property> {0 or more}
        <propertySetRef> {0 or more}
        <extendedProperty> {0 or more}
            <name> {1}
            <values> {1}
                <value> {1 or more}
        <extendedPropertySetRef> {0 or more}

Example

See <propertySet> for an example.

 


<propertySets>

This element specifies a set of property sets.

Parent Element

<jpsConfig>

Child Element

<propertySet>

Occurrence

Optional. If present, there can be only one <propertySets> element.

<jpsConfig>
    <propertySets> {0 or 1}
        <propertySet> {1 or more}
            <property> {1 or more}

Example

See <propertySet> for an example.

 


<serviceInstance>

This element defines an instance of a service provider, such as an identity store service instance, policy store service instance, or login module service instance.

Each provider instance specifies the name of the instance, used to refer to the provider within the configuration file; the name of the provider being instantiated; and, possibly, the properties of the instance. Properties include the location of the instance and can be specified directly, within the instance element itself, or indirectly, by referencing a property or a property set. To change the properties of a service instance, you can use the procedure explained in Section E.1, "Configuring OPSS Service Provider Instances with a WLST Script."

Set properties and extended properties of a service instance in the following ways:

Attributes

NameDescription
nameDesignates a name for this service instance. Note that no two <serviceInstance> elements may have the same name attribute setting within a jps-config.xml file.

Values: string

Default: n/a (required)

providerIndicates which service provider this is an instance of.

The provider value of a <serviceInstance> element must match the name value of a <serviceProvider> element.

Values: string

Default: n/a (required)


Parent Element

<serviceInstances>

Child Elements

<description>, <extendedProperty>, <extendedPropertySetRef>, <property>, or <propertySetRef>

Occurrence

Required within <serviceInstances>, one or more.

<serviceInstances> {0 or 1}
    <serviceInstance> {1 or more}
        <description> {0 or 1}
        <property> {0 or more}
        <propertySetRef> {0 or more}
        <extendedProperty> {0 or more}
            <name> {1}
            <values> {1}
                <value> {1 or more}
        <extendedPropertySetRef> {0 or more}

Examples

Example 1   

The following example illustrates the configuration of a file-based identity store service. For a file-based identity store, the subscriber name is the default realm. The example sets the lo cation using the location property.

<serviceInstances>
   <serviceInstance name="idstore.xml" provider="idstore.xml.provider">
      <!-- Subscriber name must be defined for XML Identity Store -->
      <property name="subscriber.name" value="jazn.com"/>
      <!-- This is the location of XML Identity Store -->
      <property name="location" value="./system-jazn-data.xml"/>
   </serviceInstance>
...
</serviceInstances>
Example 2   

The following example illustrates the configuration a credential store service. It uses the location property to set the location of the credential store.

<serviceInstances>
   <serviceInstance provider="credstoressp" name="credstore">
      <description>File Based Default Credential Store Service
                  Instance</description>
      <property name="location"
                value="${oracle.instance}/config/JpsDataStore/JpsSystemStore" />
   </serviceInstance>
...
</serviceInstances>
Example 3   

The following example illustrates the configuration of an LDAP-based identity store using Oracle Internet Directory:

<serviceInstance name="idstore.oid" provider="idstore.ldap.provider">
   <property name="subscriber.name" value="dc=us,dc=oracle,dc=com"/>
   <property name="idstore.type" value="OID"/>
   <property name="security.principal.key" value="ldap.credentials"/>
   <property name="security.principal.alias" value="JPS"/>
   <property name="ldap.url" value="ldap://myServerName.com:389"/>
   <extendedProperty>
      <name>user.search.bases</name>
      <values>
         <value>cn=users,dc=us,dc=oracle,dc=com</value>
      </values>
   </extendedProperty>
   <extendedProperty>
      <name>group.search.bases</name>
      <values>
         <value>cn=groups,dc=us,dc=oracle,dc=com</value>
      </values>
   </extendedProperty>
   <property name="username.attr" value="uid"/>
   <property name="groupname.attr" value="cn"/>
</serviceInstance>
Example 4   

The following example illustrates the configuration of an audit provider:

<serviceInstances>
   <serviceInstance name="audit" provider="audit.provider">
      <property name="audit.filterPreset" value="Low"/>
      <property name="audit.specialUsers" value ="admin, fmwadmin" />
      <property name="audit.customEvents" value ="JPS:CheckAuthorization,           CreateCredential, OIF:UserLogin"/>
      <property name="audit.loader.jndi" value="jdbc/AuditDB"/>
      <property name="audit.loader.interval" value="15" />
      <property name="audit.maxDirSize" value="102400" />
      <property name="audit.maxFileSize" value="10240" />      
      <property name=" audit.loader.repositoryType " value="Db" />      
   </serviceInstance>
  </serviceInstances>

See Also:


 


<serviceInstanceRef>

This element refers to service instances.

Attributes

NameDescription
ref              Refers to a service instance that are part of the context defined in the <jpsContext> parent element. The ref value of a <serviceInstanceRef> element must match the name of a <serviceInstance> element.

Values: string

Default: n/a (required)


Parent Element

<jpsContext>

Child Element

None

Occurrence

Required within a <jpsContext>, one or more.

<jpsContexts> {1}
    <jpsContext> {1 or more}
        <serviceInstanceRef> {1 or more}

Example

See <jpsContext> for an example.

 


<serviceInstances>

This element is the parent of a <serviceInstance> element.

Parent Element

<jpsConfig>

Child Element

<serviceInstance>

Occurrence

Optional, zero or one.

<jpsConfig>
    <serviceInstances> {0 or 1}
        <serviceInstance> {1 or more}
            <description> {0 or 1}
            <property> {0 or more}
            <propertySetRef> {0 or more}
            <extendedProperty> {0 or more}
                <name> {1}
                <values> {1}
                    <value> {1 or more}
            <extendedPropertySetRef> {0 or more}

Example

See <serviceInstance> for an example.

 


<serviceProvider>

This element defines a service provider. Each provider specifies the type of the provider, such as credential store, authenticators, policy store, or login module; the name of the provider, used to refer to the provider within the configuration file; and the Java class that implements the provider and that is instantiated when the provider is created. Furthermore, the element property specifies settings used to instantiate the provider.

It specifies the following data:

Attributes

NameDescription
typeSpecifies the type of service provider being declared; it must be either of the following:

CREDENTIAL_STORE

IDENTITY_STORE

POLICY_STORE

AUDIT

LOGIN

ANONYMOUS

KEY_STORE

IDM (for pluggable identity management)

CUSTOM

The implementation class more specifically defines the type of provider, such as by implementing a file-based identity store or LDAP-based policy store, for example.

Values: string (a value above)

Default: n/a (required)

nameDesignates a name for this service provider. This name is referenced in the provider attribute of <serviceInstance> elements to create instances of this provider. No two <serviceProvider> elements may have the same name attribute setting within a configuration file.

Values: string

Default: n/a (required)

classSpecifies the fully qualified name of the Java class that implements this service provider (and that is instantiated to create instances of the service provider).

Values: string

Default: n/a (required)


Parent Element

<serviceProviders>

Child Elements

<description> or <property>

Occurrence

Required within the <serviceProviders> element, one or more.

<serviceProviders> {0 or 1}
    <serviceProvider> {1 or more}
        <description> {0 or 1}
        <property> {0 or more}

Examples

The following example illustrates the specification of a login module service provider:

<serviceProviders>
   <serviceProvider type="LOGIN" name="jaas.login.provider"
        class="oracle.security.jps.internal.login.jaas.JaasLoginServiceProvider">
      <description>This is Jaas Login Service Provider and is used to configure
       login module service instances</description>
   </serviceProvider>
</serviceProviders>

The following example illustrates the definition of an audit service provider:

 <serviceProviders>
     <serviceProvider name="audit.provider" type="AUDIT" class="oracle.security.jps.internal.audit.AuditProvider">
     </serviceProvider>
    </serviceProviders>

See <serviceInstance> for other examples.

 


<serviceProviders>

This element specifies a set of service providers.

Parent Element

<jpsConfig>

Child Element

<serviceProvider>

Occurrence

Optional, one only.

<jpsConfig>
    <serviceProviders> {0 or 1}
        <serviceProvider> {1 or more}
            <description> {0 or 1}
            <property> {0 or more}

Example

See <serviceProvider> for an example.

 


<value>

This element specifies a value of an extended property, which can have multiple values. Each <value> element specifies one value.

Parent Element

<values>

Child Element

None.

Occurrence

Required within <values>, one or more.

    <extendedProperty> {0 or more}
        <name> {1}
        <values> {1}
            <value> {1 or more}

Example

See <extendedProperty> for an example.

 


<values>

This element is the parent element of a <value> element.

Parent Element

<extendedProperty>

Child Element

<value>

Occurrence

Required within <extendedProperty>, one only.

<extendedProperty> {0 or more}
    <name> {1}
    <values> {1}
        <value> {1 or more}

Example

See <extendedProperty> for an example.

 

PKV{(  PKfp@OEBPS/csfadmin.htmhy Managing the Credential Store

10 Managing the Credential Store

A credential can hold user names, passwords, and tickets; credentials can be encrypted. Credentials are used during authentication, when principals are populated in subjects, and, further, during authorization, when determining what actions the subject can perform.

Oracle Platform Security Services includes the Credential Store Framework (CSF), a set of APIs that applications can use to create, read, update, and manage credentials securely. A typical use of the credential store is to store user names and passwords to access some external system, such as a database or an LDAP-based repository.

This chapter is divided into the following sections:

10.1 Credential Types

OPSS supports the following types of credentials according to the data they contain:

In CSF, a credential is uniquely identified by a map name and a key name. Typically, the map name corresponds with the name of an application and all credentials with the same map name define a logical group of credentials, such as the credentials used by the application. The pair of map and key names must be unique for all entries in a credential store.

Oracle Wallet is the default file-based credential store, and it can store X.509 certificates; production environments typically use either an Oracle Internet Directory LDAP-based or an RDBMS DB-based credential store.

10.2 Encrypting Credentials

OPSS supports storing encrypted data in file- and LDAP-based credential stores. (In case of DB-based credential stores, data is always encrypted.) OPSS uses an encryption key to encrypt and decrypt data when it is read from or written to the credential store. To enable the encryption of credentials in a file- or LDAP-based store, set the following property in the credential store service instance of the file jps-config.xml:

<property name="encrypt" value="true" />

By default, credentials are kept in clear-text.

The Encryption Key

Assuming the above property set, OPSS automatically generates a random 256-bit AES key when the domain is restarted. Since the keys generated are practically distinct, a domain uses a unique encryption key. In addition to the first generated encryption key, there may be other keys (roll-over keys) automatically generated over time and used to encrypt and decrypt data. The only way to get a roll-over key is by restarting the domain.

When a new roll-over key is produced, data in the credential store is not immediately re-encrypted with the new key. Instead, data is re-encrypted (with the new key) only when it is written. This implies that to get all data to use the same encryption key, all credentials must be read and written.

Domains Sharing a Credential Store

If two or more domains share a credential store and encryption is enabled in that store, then each of those domains must use the same encryption key; this applies regardless of the type, LDAP or DB, of the credential store. To ensure this, OPSS provides offline scripts to export, import, and restore keys in the domain bootstrap wallet, so that an encryption key generated in one domain can be carried over to all other domains sharing the credential store. For details about these commands, see Managing Credentials with OPSS Scripts.

The following scenarios illustrate how to set credential encryption in a cluster of two domains, Domain1 and Domain2. (In case of more than two domains, treat each additional domain as Domain2 in the illustration below.)


Note:

The following scenarios assume that the credential store is LDAP-based, but the use of exportEncryptionKey and exportEncryptionKey to import and export keys across domains applies also to DB-based credential stores (in which data is always encrypted).

First Scenario

Assume that Domain1 has reassociated to an LDAP-based credential store, and Domain2 has not yet joined to that store. Then, to enable credential encryption on that store, proceed as follows:

  1. Set the property encrypt to true in Domain1's jps-config.xml file and restart the domain.

  2. Use the OPSS script exportEncryptionKey to extract the key from Domain1's bootstrap wallet into the file ewallet.p12; note that the value of the argument keyFilePassword passed to the script must be used later when importing that key into another domain.

  3. Set the property encrypt to true in Domain2's jps-config.xml file.

At this point you can complete the procedure in one of two ways; both of them use the OPSS script reassociateSecurityStore, but with different syntaxes. For details about this script, see Section 9.3.29, "reassociateSecurityStore."

The first approach is as follows:

  1. Use the OPSS script reassociateSecurityStore to reassociate Domain2's credential store to that used by Domain1; use the argument join and do not use the arguments keyFilePassword and keyFilePath.

  2. Use the OPSS script importEncryptionKey to write the extracted ewallet.p12 into Domain2's bootstrap wallet; note that the value of the argument keyFilePassword must be identical to the one used when the file ewallet.p12 was generated.

  3. Restart Domain2's server.

The second approach is as follows:

  1. Use the OPSS script reassociateSecurityStore to reassociate Domain2's credential store to that used by Domain1; use the arguments join, keyFilePassword, and keyFilePath.

  2. Restart Domain2's server.

Second Scenario

Assume that Domain1 has reassociated to an LDAP-based credential store and Domain2 has already joined to that store. Then, to enable credential encryption on that store, proceed as follows:

  1. Set the property encrypt to true in Domain1's jps-config.xml file and restart the domain.

  2. Use the OPSS script exportEncryptionKey to extract the key from Domain1's bootstrap wallet into the file ewallet.p12; note that the value of the argument keyFilePassword passed to the script must be used later when importing that key into another domain.

  3. Set the property encrypt to true in Domain2's jps-config.xml file.

  4. Use the OPSS script importEncryptionKey to write the extracted ewallet.p12 into Domain2's bootstrap wallet; note that the value of the argument keyFilePassword must be identical to the one used when the file ewallet.p12 was generated.

  5. Restart Domain2's server.


Important Note:

In case of multiple domains sharing a credential store in which encryption has been enabled, every time a roll-over key is generated in one of those domains, the administrator must import that key to each of the other domains in the cluster using the OPSS scripts exportEncryptionKey and importEncryptionKey.

10.3 Managing the Credential Store

Credentials can be provisioned, retrieved, modified, or deleted, but only by a user in the appropriate administration role. The following sections explain how an administrator can manage credentials using Fusion Middleware Control pages or OPSS scripts, and how code can access data in the CSF.

10.4 Managing Credentials with Fusion Middleware Control

The following procedure explains how to use Fusion Middleware Control to manage credentials.

  1. Log in to Fusion Middleware Control and navigate to Domain > Security > Credentials (if the application is deployed on Oracle WebLogic Server), or to Cell > Security > Application Policies (if it is deployed on WebSphere Application Server), to display the Credentials page partially illustrated in the following graphic:

    credential store page

    The area Credential Store Provider is read-only; when expanded, it displays the credential store provider currently in use in the domain or cell.

  2. To display credentials matching a given key name, enter the string to match in the Credential Key Name box, and then click the blue button. The result of the search is displayed in the table at the bottom of the page.

  3. At any point, you can remove an item by selecting it and clicking the Delete button; similarly, you can modify an item from the table by selecting it and clicking Edit button. Note that deleting a credential map, deletes all keys in it.

To create a credential map:

  1. Click Create Map to display the Create Map dialog.

  2. In this dialog, enter the name of the map for the credential being created.

  3. Click OK to return to the Credentials page. The new credential map name is displayed with a map icon in the table.

To add a key to a credential map:

  1. Click Create Key to display the Create Key dialog.

  2. In this dialog, select a map from the menu Select Map for the key being created, enter a key in the text Key box, and select a type (Password or Generic) from the pull-down menu Type. The dialog display changes according the type selected.

    If Password was selected, enter the required fields (Key, User Name, Password, Confirm Passwords).

    If Generic was selected, enter the required field Key and the credential information either as text (select Enter as Text radio button), or as a list of key-value pairs (select Enter Map of Property Name and Value Pairs radio button); to add a key-value pair, click Add Row, and then enter the Property Name, Value, and Confirm Value in the added arrow.

    Figure 10-1 illustrates th dialog used to create a password key.

  3. Click OK to return to the Credentials page. The new key is displayed under the map icon corresponding to the map you selected.

To edit a key:

  1. Select a key from the table.

  2. Click Edit to bring up the Edit Key dialog.

  3. In that dialog, modify the key data as appropriate. In case of editing a generic key, use the red X next to a row to delete the corresponding property-value pair.

    Figure 10-2 illustrates the dialog used to edit a generic key.

  4. Click OK to save your changes and return to the Credentials page.

For specific considerations that apply to ADF applications only, see section How to Edit Credentials Deployed with the Application in Oracle Fusion Middleware Administrator's Guide for Oracle Application Development Framework.

10.5 Managing Credentials with OPSS Scripts

An OPSS script is either a WLST script, in the context of the Oracle WebLogic Server, or a WASAdmin script, in the context of the WebSphere Application Server. The scripts listed in this section apply to both platforms: WebLogic Application Server and WebSphere Application Server.

An online script is a script that requires a connection to a running server. Unless otherwise stated, scripts listed in this section are online scripts and operate on a policy store, regardless of whether it is file-, LDAP-, or DB-based. There are a few scripts that are offline, that is, they do not require a server to be running to operate.

Read-only scripts can be performed only by users in the following WebLogic groups: Monitor, Operator, Configurator, or Admin. Read-write scripts can be performed only by users in the following WebLogic groups: Admin or Configurator. All WLST scripts are available out-of-the-box with the installation of the Oracle WebLogic Server.

WLST scripts can be run in interactive mode or in script mode. In interactive mode, you enter the script at a command-line prompt and view the response immediately after. In script mode, you write scripts in a text file (with a py file name extension) and run it without requiring input, much like the directives in a shell script.

WASAdmin scripts can be run in interactive mode only. For details, see Oracle Fusion Middleware Third-Party Application Server Guide.

For platform-specific requirements to run an OPSS script, see Important Note.

OPSS provides the following scripts on all supported platforms to administer credentials (all scripts are online, unless otherwise stated):

PKkmyhyPKfp@OEBPS/gsofmsec.htmY[ Security Administration

5 Security Administration

This chapter introduces the tools available to an administrator and the typical tasks to manage application security; it is divided into the following sections:

For advanced administrator tasks, see Appendix E, "Administration with WLST Scripting and MBean Programming."

5.1 Choosing the Administration Tool According to Technology

The four basic tools available to a security administrator are Oracle Enterprise Manager Fusion Middleware Control, Oracle WebLogic Administration Console, Oracle Entitlements Server, and the Oracle WebLogic Scripting Tool (WLST). For further details on these and other tools, see chapter 3, Getting Started Managing Oracle Fusion Middleware in Oracle Fusion Middleware Administrator's Guide.

The main criterion that determines the tool to use to administer application security is whether the application uses just container-managed security (Java EE application) or it includes Oracle ADF security (Oracle ADF application).

Oracle-specific applications, such as Oracle Application Development Framework (Oracle ADF) applications, Oracle Server-Oriented Architecture (SOA) applications, and Web Center applications, are deployed, secured, and maintained with Fusion Middleware Control and Oracle Entitlements Server.

Other applications, such as those developed by third parties, Java SE, and Java EE applications, are typically deployed, secured, and administered with Oracle WebLogic Administration Console or with WLST.

The recommended tool to develop Java applications is Oracle JDeveloper 11g. This tool helps the developer configure file-based identity, policy, and credential stores through specialized graphical editors. In particular, when developing Oracle ADF applications, the developer can run a wizard to configure security for web pages associated with Oracle ADF resources (such as Oracle ADF task flows and page definitions), and define security artifacts using a specialized, visual editor for the file jazn-data.xml.

For details about procedures and related topics, see the following sections in the Oracle JDeveloper online help documentation:

  • Securing a Web Application Using Oracle ADF Security

  • Securing a Web Application Using Java EE Security

  • About Oracle ADF Security as an Alternative to Security Constraints

  • About Securing Web Applications

For further details about Oracle ADF Security and its integration with Oracle JDeveloper, see Accessing the Oracle ADF Security Design Time Tools, in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

For further details about Oracle Entitlements Server, see Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

5.2 Basic Security Administration Tasks

Table 5-1 lists some basic security tasks and the tools used to execute them. Recall that the tool chosen to configure and manage application security depends on the type of the application: for Java EE applications, which use just container-managed security, use the Oracle WebLogic Administration Console; for Oracle ADF applications, which use OPSS authorization, use Fusion Middleware Control and Oracle Entitlements Server.

Manual settings without the aid of the tools listed below are not recommended. For information about using the Oracle WebLogic Administration Console, see the list of links following the table below. For details about Oracle Entitlements Server, see Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

Details about using the Oracle WebLogic Administration Console for the tasks above are found in the following documents:

5.3 Typical Security Practices with Fusion Middleware Control

Fusion Middleware Control is a Web-based tool that allows the administration of a network of applications from a single point. Fusion Middleware Control is used to deploy, configure, monitor, diagnose, and audit Oracle SOA applications, Oracle ADF applications, Oracle WebCenter, and other Oracle applications using OPSS. Note that this section mentions only security-related operations.

In regards to security, it provides several administration tasks; using this tool, an administrator can:

For a summary of security administrative tasks and the tools used to execute them, see Basic Security Administration Tasks.

For further details about other functions, see the Fusion Middleware Control online help documentation.

For details about managing Oracle Fusion Middleware on WebSphere Application Server, see Oracle Fusion Middleware Third-Party Application Server Guide.

5.4 Typical Security Practices with the Administration Console

The Oracle WebLogic Administration Console is a Web-based tool that allows, among other functions, application deployment and redeployment, domain configuration, and monitoring of application status. Note that this section mentions only security-related operations.

Typical tasks performed with the Oracle WebLogic Administration Console include the following:

For details about Oracle WebLogic Administration Console, see Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

5.5 Typical Security Practices with Oracle Entitlements Server

Typical security tasks performed with Oracle Entitlements Server include the following:

  • Searching application security artifacts.

  • Managing application security artifacts, including policies.

  • Viewing the external role hierarchy.

  • Managing the application role hierarchy.

For a list of some of the most frequent security tasks to administer application security with Oracle Entitlements Server, see Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

5.6 Typical Security Practices with OPSS Scripts

Most of the operations available in the Oracle WebLogic Administration Console can be effected with OPSS scripts, a set of command-line interface that allows the scripting and automation of administration tasks, including domain configuration and application deployment.

For the list of security-related OPSS scripts, see Appendix I, "OPSS Scripts." For the complete list of WLST scripts, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For details about managing Oracle Fusion Middleware on WebSphere Application Server, see Oracle Fusion Middleware Third-Party Application Server Guide.

PKP^[Y[PKfp@OEBPS/devauthoriz.htm> Authorization for Java SE Applications

23 Authorization for Java SE Applications

This chapter explains how to develop and configure authorization in Java SE applications and lists some unsupported methods in the following sections:

For details about the policy model, see Section 20.3, "The JAAS/OPSS Authorization Model."

23.1 Configuring Policy and Credential Stores in Java SE Applications

The configuration of policy and credential stores in Java SE applications is explained in the following sections:

For details about configuring authentication for Java SE applications, see Section 22.2, "Authentication for Java SE Applications."

System properties should be set, as appropriate, for authorization to work in Java SE applications. For a complete list of properties, see Section F.1, "OPSS System Properties."

A Java SE application can use file-, LDAP-, or DB-based store providers; these services are configured in the application file jps-config-jse.xml.

23.1.1 Configuring File-Based Policy and Credential Stores

A file-based policy store is specified in the file system-jazn-data.xml; a file-based credential store is specified in the file cwallet.sso (this wallet file should not be confused with the bootstrap file, also named cwallet.sso, which contains the credentials to access LDAP stores, when the application security is LDAP-based).

For details about wallets, see Section 21.4.3, "Using a Wallet-Based Credential Store." For details about modifying or adding bootstrap credentials, see Section 10.5.5, "modifyBootStrapCredential," and Section 10.5.6, "addBootStrapCredential."

The following fragments illustrate the configuration of file-based policy and credential stores, and the jpsContext that reference them:

<serviceProviders>
  <serviceProvider type="CREDENTIAL_STORE" name="credstoressp"
        class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider">
    <description>SecretStore-based CSF Provider</description>
  </serviceProvider>
  <serviceProvider type="POLICY_STORE" name="policystore.xml.provider"
        class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider">
  <description>XML-based PolicyStore Provider</description>
  </serviceProvider>
</serviceProviders>

<serviceInstances>
  <serviceInstance name="credstore" provider="credstoressp" location="./">
    <description>File-based Credential Store Service Instance</description>
  </serviceInstance>
 
  <serviceInstance name="policystore.xml" provider="policystore.xml.provider" location="./system-jazn-data.xml">
   <description>File-based Policy Store Service Instance</description>
   <property name="oracle.security.jps.policy.principal.cache.key" value="false"/>
  </serviceInstance>
</serviceInstances>

<jpsContexts default="TestJSE">
  <jpsContext name="TestJSE">
            <serviceInstanceRef ref="credstore"/>
            <serviceInstanceRef ref="policystore.xml"/>
    ...
  </jpsContext>
  ...
</jpsContexts>

Note the required setting of the property oracle.security.jps.policy.principal.cache.key to false in the policy store instance.

23.1.2 Configuring LDAP-Based Policy and Credential Stores

This section assumes that an LDAP-based store has been set to be used as the policy and credential stores; for details about setting up nodes in an Oracle Internet Directory, see section Section 8.2.2, "Prerequisites to Using an LDAP-Based Security Store."

The following fragments illustrate the configurations of providers and instances for LDAP-based policy and credential stores for a Java SE application:

<serviceProviders
  <serviceProvider type="POLICY_STORE" mame="ldap.policystore.provider"
 class=oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider"/>
   
  <serviceProvider type="CREDENTIAL_STORE" mame="ldap.credential.provider"
 class=oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider"/>
</serviceProviders>

<serviceInstances>
 <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
  <property value="OID" name="policystore.type"/>
  <property value="bootstrap" name="bootstrap.security.principal.key"/>
  <property value="cn=PS1domainRC3" name="oracle.security.jps.farm.name"/>
  <property value="cn=myTestNode" name="oracle.security.jps.ldap.root.name"/>
  <property value="ldap://myComp.com:1234" name="ldap.url"/>
 </serviceInstance>

 <serviceInstance provider="ldap.credential.provider" name="credstore.ldap">
  <property value="bootstrap" name="bootstrap.security.principal.key"/>
  <property value="cn=PS1domainRC3" name="oracle.security.jps.farm.name"/>
  <property value="cn=myTestNode" name="oracle.security.jps.ldap.root.name"/>
  <property value="ldap://myComp.com:1234" name="ldap.url"/>
 </serviceInstance>
</serviceInstances>

The following fragment illustrates the configuration of the bootstrap credentials file (cwallet.sso), which allows the program access to the LDAP server:

<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
  <property value="./bootstrap" name="location"/>
</serviceInstance>

The following fragment illustrates the configuration of the necessary jpsContexts that reference the instances above:

<jpsContexts default="TestJSE">
  <jpsContext name="TestJSE">
    <serviceInstanceRef ref="policystore.ldap"/>
    <serviceInstanceRef ref="credstore.ldap"/>
  </jpsContext>
  <jpsContext name="bootstrap_credstore_context">
    <serviceInstanceRef ref="bootstrap.cred"/>  
  </jpsContext>
</jpsContexts>

The following code fragment illustrates how to obtain programmatically a reference to the LDAP-based policy store configured above, and it assumes that the system property oracle.security.jps.config has been set to the location of the file jps-config-jse.xml:

String contextName="TestJSE"; ...
public static PolicyStore getPolicyStore(String contextName) {
      try-block    
            JpsContextFactory ctxFact;  
            ctxFact = JpsContextFactory.getContextFactory();   
            JpsContext ctx = ctxFact.getContext(contextName);  
            return ctx.getServiceInstance(PolicyStore.class);      
      catch-block
...

23.1.3 Configuring DB-Based OPSS Security Stores

This section assumes that a DB-based store has been set to be used as the OPSS security store. For details about setting up nodes in a DB, see section Section 8.3.1, "Prerequisites to Using a DB-Based Security Store."

Note the following important points regarding the sample configuration below:

  • The value of the configuration property jdbc.url should be identical to the name of the JDBC data source entered when the data source was created.

  • The values of the bootstrap credentials (map and key) must match those passed to the WLST script addBootStrapCredential when the bootstrap credential was created.

The following fragment illustrates configuration of DB-based policy, credential, and key stores in the file jps-config-jse.xml:

<jpsConfig  …>
  <propertySets>
   <propertySet name="props.db.1">
    <property value="cn=myDomain" name="oracle.security.jps.farm.name"/>
    <property value="DB_ORACLE" name="server.type"/>
    <property value="cn=myRoot" name="oracle.security.jps.ldap.root.name"/>
    <property name="jdbc.url" value="jdbc:oracle:thin:@myhost.com:1521/srv_name"/>
    <property name="jdbc.driver" value="oracle.jdbc.driver.OracleDriver"/>
    <property name="bootstrap.security.principal.key" value="myKeyName" />
    <property name="bootstrap.security.principal.map" value="myMapName" />
   </propertySet> 
  </propertySets>
  <serviceProviders>
    <serviceProvider class="oracle.security.jps.internal.policystore.OPSSPolicyStoreProvider"
           type="POLICY_STORE" name="policy.rdbms">
      <description>DBMS based PolicyStore</description>
    </serviceProvider>

    <serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider"
               type="CREDENTIAL_STORE" name="db.credentialstore.provider" >

  <serviceProvider class="oracle.security.jps.internal.keystore.KeyStoreProvider" 
               type="KEY_STORE" name="keystore.provider" >
    <property name="provider.property.name" value="owsm"/>
  </serviceProvider>
 </serviceProviders>
 
 <serviceInstances>
   <serviceInstance name="policystore.rdbms" provider="db.policystore.provider">  
    <propertySetRef ref = "props.db.1"/>
    <property name="policystore.type"  value="DB_ORACLE"/>
   </serviceInstance>

   <serviceInstance name="credstore.rdbms" provider="db.credstore.provider">
    <propertySetRef ref = "props.db.1"/>  
   </serviceInstance>
 
   <serviceInstance name="keystore.rdbms" provider="db.keystore.provider">  
    <propertySetRef ref = "props.db.1"/> 
    <property name="keystore.provider.type"  value="db"/>
   </serviceInstance>
  </serviceInstances>
 
  <jpsContexts default="default">
    <jpsContext name="default">
      <serviceInstanceRef ref="policystore.rdbms"/>      
      <serviceInstanceRef ref="credstore.rdbms"/>
      <serviceInstanceRef ref="keystore.rdbms"/>
    </jpsContext>
  </jpsContexts>
</jpsConfig>

23.2 Unsupported Methods for File-Based Policy Stores

This release does not support, for file-based policy stores, methods involving the following features:

  • Bulk authorization

  • Complex queries

  • Cascading deletions

Bulk authorization is encapsulated in the following method of the interface oracle.security.jps.service.policystore:

java.util.Set<ResourceActionsEntry>
checkBulkAuthorization(javax.security.auth.Subject subject,
                       java.util.Set<ResourceActionsEntry> requestedResources)
                       throws PolicyStoreException

Complex queries relates to any method that takes a query. When the policy store is file-based, the query must be simple; if such a method is passed a complex query and the policy store is file-based, the method will throw an exception.

A simple query is a query with just one search criterion; a complex query is a query with two or more search criteria; each call to addQuery adds a criterion to the query.

The following code fragment that illustrates the building of a simple query that returns of all permissions with a display name matching the string MyDisplayName:

PermissionSetSearchQuery query = new PermissionSetSearchQuery();
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.DISPLAY_NAME,
               false,
               ComparatorType.EQUALITY,
               "MyDisplayName",
               BaseSearchQuery.MATCHER.EXACT);
getPermissionSets(query);

The following example illustrates the building of a complex query that returns all permission sets with a given resource type and a given resource instance name:

PermissionSetSearchQuery query = new PermissionSetSearchQuery();
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.RESOURCE_TYPE,
               false,
               ComparatorType.EQUALITY, 
               "MyResourceType",
               BaseSearchQuery.MATCHER.EXACT);
  
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.RESOURCE_NAME,
               false, 
               ComparatorType.EQUALITY, 
               "MyResourceInstanceName", 
               BaseSearchQuery.MATCHER.EXACT);
 
query.setANDMatch();
getPermissionSets(query);

Cascading deletions relates to any method that includes the Boolean argument cascadeDelete. The only value allowed for this argument in case the policy store is file-based is FALSE. Here is an example of such a method in the interface ResourceTypeManager:

void deleteResourceType(EntryReference rtRef, boolean cascadeDelete)
                 throws PolicyObjectNotFoundException,
                        PolicyStoreOperationNotAllowedException,
                        PolicyStoreException
PK>>PKfp@OEBPS/polmodel.htm The OPSS Policy Model

20 The OPSS Policy Model

This chapter explains the OPSS policy and authorization models in the following sections:

20.1 The Security Policy Model

For details about the OPSS policy model and the security artifacts used in it, see Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

20.2 Authorization Overview

This section compares and contrasts the authorization available in the Java EE and the JAAS models, in the following sections:

20.2.2 The Java EE Authorization Model

The Java EE authorization model uses role membership to control access to EJB methods and web resources that are referenced by URLs; policies assign permissions to users and roles, and they are enforced by the container to protect resources.

In the Java EE model, authorization is implemented in either of the following ways:

  • Declaratively, where authorization policies are specified in deployment descriptors; the container reads those policies from deployment descriptors and enforces them. No special application code is required to enforce authorization.

  • Programmatically, where authorization policies are checked in application code; the code checks whether a subject has the appropriate permission to execute specific sections of code. If the subject fails to have the proper permission, the code throws an exception.

Table 20-1 shows the advantages and disadvantages of each approach.

A container can provide authorization to applications running in it in two ways: declaratively and programmatically; these topics and an example are explained in the following sections:

20.2.2.3 Java EE Code Example

The following example illustrates a servlet calling the method isUserInRole. It is assumed that the EAR file packing the servlet includes the configuration files web.xml and weblogic-application.xml, and that these files include the following configuration fragments:

web.xml

 <!-- security roles -->
 <security-role>
   <role-name>sr_developer</role-name>
 </security-role>

weblogic-application.xml

The following snippet shows the mapping between the user weblogic and the security role sr_developer:

<wls:security-role-assignment>
  <wls:role-name>sr_developer</wls:role-name>
  <wls:principal-name>weblogic</wls:principal-name>
</wls:security-role-assignment>

Code Example Invoking isUserInRole

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.Date;

public class PolicyServlet extends HttpServlet {
 
 public PolicyServlet() {
        super();
    }

 public void init(ServletConfig config)
            throws ServletException {
        super.init(config);
    }

 public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        final ServletOutputStream out = response.getOutputStream();
 
        response.setContentType("text/html");
        out.println("<HTML><BODY bgcolor=\"#FFFFFF\">");
        out.println("Time stamp: " + new Date().toString());
        out.println( "<br>request.getRemoteUser = " + request.getRemoteUser() + "<br>");
        out.println("request.isUserInRole('sr_developer') = " + request.isUserInRole("sr_developer") + "<br>");
        out.println("request.getUserPrincipal = " + request.getUserPrincipal() + "<br>");
        out.println("</BODY>");
        out.println("</HTML>");
    }
}

20.3 The JAAS/OPSS Authorization Model

JAAS/OPSS authorization is based on controlling the operations that a class can perform when it is loaded and run in the environment.

This section is divided into the following sections:

20.3.2 Managing Policies

Resource catalog artifacts can be managed with the policy management API. Specifically, the following interfaces, all subinterfaces of the interface oracle.security.jps.service.policystore.EntityManager, are directly relevant to the artifacts in the resource catalog:

For details about these interfaces, see the Javadoc document Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services.

The following code snippet illustrates the creation of a resource type, a resource instance, actions, and a permission set:

import oracle.security.jps.service.policystore.entitymanager.*;
import oracle.security.jps.service.policystore.search.*;
import oracle.security.jps.service.policystore.info.resource.*;
import oracle.security.jps.service.policystore.info.*;
import oracle.security.jps.service.policystore.*;
import java.util.*;
 
public class example {
  public static void main(String[] args) throws Exception {
     ApplicationPolicy ap;

     ResourceTypeManager rtm = ap.getEntityManager(ResourceTypeManager.class);
     ResourceTypeSearchQuery query = new ResourceTypeSearchQuery();
     query.setANDMatch();
     query.addQuery(ResourceTypeSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "resourceType", BaseSearchQuery.MATCHER.EXACT);
     List<ResourceTypeEntry> allResourceTypes = rtm.getResourceTypes(query);

     ResourceManager rm = ap.getEntityManager(ResourceManager.class);
     ResourceSearchQuery ResourceQuery = new ResourceSearchQuery();
     ResourceQuery.setANDMatch();
     ResourceQuery.addQuery(ResourceSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "R2", BaseSearchQuery.MATCHER.EXACT);
     List<ResourceEntry> allResources = rm.getResources("RT2", ResourceQuery);

     PermissionSetManager psm = ap.getEntityManager(PermissionSetManager.class);
     PermissionSetSearchQuery pssq = new PermissionSetSearchQuery();
     pssq.setANDMatch();
     pssq.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "PS1", BaseSearchQuery.MATCHER.EXACT);
     List<PermissionSetEntry> allPermSets = psm.getPermissionSets(pssq);

     RoleCategoryManager rcm = ap.getEntityManager(RoleCategoryManager.class);
     RoleCategorySearchQuery rcsq = new RoleCategorySearchQuery();
     rcsq.setANDMatch();
     rcsq.addQuery(RoleCategorySearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "roleCategoryCartoon",      BaseSearchQuery.MATCHER.EXACT);

     List<RoleCategoryEntry> allRoleCategories = rcm.getRoleCategories(rcsq);
  }
}

The following code snippet illustrates a complex query involving resource catalog elements:

//ApplicationPolicy ap as in the preceeding example
ResourceTypeManager rtm = ap.getEntityManager(ResourceTypeManager.class);
ResourceTypeSearchQuery query = new ResourceTypeSearchQuery();
query.setANDMatch();
query.addQuery(ResourceTypeSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "resourceType", BaseSearchQuery.MATCHER.EXACT);
List<ResourceTypeEntry> enties = rtm.getResourceTypes(query);
 
ResourceManager rm = ap.getEntityManager(ResourceManager.class);
ResourceSearchQuery ResourceQuery = new ResourceSearchQuery();
ResourceQuery.setANDMatch();
ResourceQuery.addQuery(ResourceSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "R2", BaseSearchQuery.MATCHER.EXACT);
ArrayList<BaseSearchQuery> querries = ResourceQuery.getQueries();
List<ResourceEntry> resources = rm.getResources("RT2", ResourceQuery);
 
PermissionSetManager psm = ap.getEntityManager(PermissionSetManager.class);
PermissionSetSearchQuery pssq = new PermissionSetSearchQuery();
pssq.setANDMatch();
pssq.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "PS1", BaseSearchQuery.MATCHER.EXACT);
List<PermissionSetEntry> psets = psm.getPermissionSets(pssq);
 
RoleCategoryManager rcm = ap.getEntityManager(RoleCategoryManager.class);
RoleCategorySearchQuery rcsq = new RoleCategorySearchQuery();
rcsq.setANDMatch();
rcsq.addQuery(RoleCategorySearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "roleCategoryCartoon", BaseSearchQuery.MATCHER.EXACT);
ArrayList<BaseSearchQuery> queries = rcsq.getQueries();
List<RoleCategoryEntry> rcs = rcm.getRoleCategories(rcsq);

The following code sample illustrates how to create a grant:

GrantManager gm = ap.getEntityManager(GrantManager.class);
Set<PrincipalEntry> pe = new HashSet<PrincipalEntry>();
List<AppRoleEntry> are = ap.searchAppRoles(appRoleName);
pe.addAll(are);
gm.grant(pe, null, permissionSetName);

20.3.3 Checking Policies

This section illustrates several ways to check policies programmatically, in the following sections:

20.3.3.1 Using the Method checkPermission

Oracle Fusion Middleware supports the use of the method checkPermission in the classes java.security.AccessController and oracle.security.jps.util.JpsAuth.

Oracle recommends the use of checkPermission in the class JpsAuth because it provides better debugging support, better performance, and audit support.

The static method AccessController.checkPermission uses the default access control context (the context inherited when the thread was created). To check permissions on some other context, call the instance method checkPermission on a particular AccessControlContext instance.

The method checkPermission behaves according to the value of the JAAS mode (see JAAS mode in Chapter 21, "Configuring the Servlet Filter and the EJB Interceptor"), as listed in the following table:

The following example illustrates a servlet checking a permission. It is assumed that the EAR file packing the servlet includes the configuration files jazn-data.xml and web.xml.

jazn-data.xml

The application file-based policy store is as follows:

<?xml version="1.0" ?>
<jazn-data>
  <policy-store>
    <applications>
      <application>
        <name>MyApp</name>
                
        <app-roles>
        <app-role>
          <name>AppRole</name>
          <display-name>AppRole display name</display-name>
          <description>AppRole description</description>
          <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
          <class>oracle.security.jps.service.policystore.ApplicationRole</class>
        </app-role>
      </app-roles>
                
      <role-categories>
        <role-category>
          <name>MyAppRoleCategory</name>
          <display-name>MyAppRoleCategory display name</display-name>
          <description>MyAppRoleCategory description</description>
        </role-category>
      </role-categories>
                
      <resource-types>
        <resource-type>
          <name>MyResourceType</name>
          <display-name>MyResourceType display name</display-name>
          <description>MyResourceType description</description>
          <provider-name>MyResourceType provider</provider-name>
          <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
          <actions-delimiter>,</actions-delimiter>
          <actions>write,read</actions>
        </resource-type>
      </resource-types>
                
      <resources>
        <resource>
          <name>MyResource</name>
          <display-name>MyResource display name</display-name>
          <description>MyResource description</description>
          <type-name-ref>MyResourceType</type-name-ref>
        </resource>
      </resources>
                
      <permission-sets>
        <permission-set>
          <name>MyEntitlement</name>
          <display-name>MyEntitlement display name</display-name>
          <description>MyEntitlement description</description>
          <member-resources>
            <member-resource>
              <type-name-ref>MyResourceType</type-name-ref>
              <resource-name>MyResource</resource-name>
              <actions>write</actions>
            </member-resource>
          </member-resources>
        </permission-set>
      </permission-sets>
                
      <jazn-policy>
        <grant>
          <grantee>
            <principals>
              <principal>
                <class>
              oracle.security.jps.service.policystore.ApplicationRole</class>
                <name>AppRole</name>
                <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
              </principal>
            </principals>
          </grantee>
                        
          <!-- entitlement-based permissions -->
          <permission-set-refs>
            <permission-set-ref>
              <name>MyEntitlement</name>
            </permission-set-ref>
          </permission-set-refs>
        </grant>
      </jazn-policy>
    </application>      
  </applications>
 </policy-store>
 <jazn-policy></jazn-policy>
</jazn-data>

web.xml

The filter JpsFilter is configured as follows:

<web-app>
 <display-name>PolicyTest: PolicyServlet</display-name>
 <filter>
  <filter-name>JpsFilter</filter-name>
  <filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
   <init-param>
    <param-name>application.name</param-name>
    <param-value>PolicyServlet</param-value>
   </init-param>
  </filter>
  <filter-mapping>
   <filter-name>JpsFilter</filter-name>
   <servlet-name>PolicyServlet</servlet-name>
   <dispatcher>REQUEST</dispatcher>
  </filter-mapping>...

Code Example

In the following example, Subject.doAsPrivileged may be replaced by JpsSubject.doAsPrivileged:

import javax.security.auth.Subject;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.io.StringWriter;
import java.security.*;
import java.util.Date;
import java.util.PropertyPermission;
import java.io.FilePermission;

public class PolicyServlet extends HttpServlet {
 
 public PolicyServlet() {
        super();
    }

 public void init(ServletConfig config)
            throws ServletException {
        super.init(config);
    }

 public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        final ServletOutputStream out = response.getOutputStream();
 
        response.setContentType("text/html");
        out.println("<HTML><BODY bgcolor=\"#FFFFFF\">");
        out.println("Time stamp: " + new Date().toString());
        out.println( "<br>request.getRemoteUser = " + request.getRemoteUser() + "<br>");
        out.println("request.isUserInRole('sr_developer') = " + request.isUserInRole("sr_developer") + "<br>");
        out.println("request.getUserPrincipal = " + req5;uest.getUserPrincipal() + "<br>");

 Subject s = null;
        s = Subject.getSubject(AccessController.getContext());
 
        out.println("Subject in servlet " + s);
        out.println("<br>");
        final RuntimePermission rtPerm = new RuntimePermission("getClassLoader");
 try {
 Subject.doAsPrivileged(s, new PrivilegedAction() {
                public Object run() {
                    try {
                        AccessController.checkPermission(rtPerm);
                        out.println("<br>");
                        out.println("CheckPermission passed for permission: " + rtPerm+ " seeded in application policy");
                        out.println("<br>");
                    } catch (IOException e) {
                        e.printStackTrace();
                        printException ("IOException", e, out);
                    } catch (AccessControlException ace) {
                        ace.printStackTrace();
                        printException ("Accesscontrol Exception", ace, out);
                    }
                    return null;
                }
            }, null);

} catch (Throwable e) {
            e.printStackTrace();
            printException("application policy check failed", e, out);
        }
        out.println("</BODY>");
        out.println("</HTML>");
    }

 void printException(String msg, Throwable e, ServletOutputStream out) {
        Throwable t;
        try {
            StringWriter sw = new StringWriter();
            PrintWriter pw = new PrintWriter(sw, true);
            e.printStackTrace(pw);
 
            out.println("<p>" + msg + "<p>");
            out.println("<code>");
            out.println(sw.getBuffer().toString());
            t = e;
            /* Print the root cause */
            while ((t = t.getCause()) != null) {
                sw = new StringWriter();
                pw = new PrintWriter(sw, true);
                t.printStackTrace(pw);
 
                out.println("<hr>");
                out.println("<p>  Caused By ... </p>");
                out.println(sw.getBuffer().toString());
            }
            out.println("</code><p>");
        } catch (IOException ioe) {
            ioe.printStackTrace();
        }
    }
}

20.3.4 The Class ResourcePermission

A permission class provides the means to control the actions that a grantee is allowed on a resource. Even though a custom permission class provides the application designer complete control over the actions, target matching, and the "implies" logic, to work as expected at runtime, a custom permission class must be specified in the system classpath of the server so that it is available and can be loaded when required. But modifying the system class path in environments is difficult and, in some environments, such modification might not be even possible.

OPSS includes the class oracle.security.jps.ResourcePermission that can be used as the permission class within any application grant to protect application or system resources. Therefore, the application developer no longer needs to write custom permission classes, since the class ResourcePermission is available out-of-the-box and can be readily used in permissions within application grants stored in any supported policy provider. This class is not designed to be used in system policies, but only in application policies.

Configuring Resource Permissions

A permission that uses the class ResourcePermission is called a resource permission, and it specifies the resource type, the resource name, and an optional list of actions according to the format illustrated in the following XML sample:

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=type,resourceName=name</name>
  <actions>character-separated-list-of-actions</actions>
</permission>

The above specification requires that the resource type encoded in the type name be defined. Even though the resource type information is not used at runtime, its definition must be present for a resource permission to be migrated successfully; moreover, resource types help administrators model resources and manage their use.

The following fragments illustrate the specifications of resource permissions and the corresponding required resource types:

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=epm.calcmgr.permission,resourceName=EPM_Calc_Manager</name>
</permission>

<resource-types>
  <resource-type>
    <name>epm.calcmgr.permission</name>
    <display-name>CalcManager ResourceType</display-name>
    <description>Resourcetype for managing CalcManager grants</description>
    <provider-name></provider-name>
    <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
    <actions-delimiter>,</actions-delimiter>
    <actions></actions>
  </resource-type>
</resource-types>

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=oracle.bi.publisher.Reports,resourceName=GLReports</name>
  <actions>develop;schedule</actions>
</permission>

<resource-types>
  <resource-type>
    <name>oracle.bi.publisher.Reports</name>
    <display-name>BI Publisher Reports</display-name>
    <provider-name></provider-name>
    <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
    <actions-delimiter>;</actions-delimiter>
    <actions>view;develop;schedule</actions>
  </resource-type>
</resource-types>

Note that a resource type associated with a resource permission can have an empty list of actions. The following important points apply to a resource permission:

  • The name must conform to the following format:

    resourceType=aType,resourceName=aName
    

    The resource type of a resource permission must be defined and it is returned by the method ResourcePermission.getType().

  • The character-separated list of actions is optional; if specified, it must be a subset of the actions specified in the associated resource type. This list is returned by the method ResourcePermission.getActions().

    The character used to separate the items of the list must equal to the character specified in the <actions-delimiter> of the associated resource type.

  • The display name of a resource used in a permission is returned by the method ResourcePermission.getResourceName().

  • No wildcard use is supported in a resource permission.

Managing and Checking Resource Permissions

The code snippet below illustrates the instantiation of a resource permission and how to check it programmatically; the following code snippet is based on one of the configuration examples described in Configuring Resource Permissions:

ResourcePermission rp = 
   new ResourcePermission("oracle.bi.publisher.Reports","GLReports","develop");
JpsAuth.checkPermission(rp);
 

At runtime the permission check will succeed if the resource permission satisfies all the following four conditions:

  • The permission is an instance of the class ResourcePermision.

  • The resource type name (first argument) matches (ignoring case) the name of a resource type.

  • The resource (second argument) name matches exactly the name of a resource instance.

  • The list of actions (third argument) is a comma-separated subset of the set of actions specified in the resource type.

About the Matcher Class for a Resource Type

When creating a resource type, a matcher class can be optionally supplied. If unspecified, it defaults to oracle.security.jps.ResourcePermission.

If, however, two or more resource types are to share the same resource matcher class, then that class must be one of the following:

PK0εĵPKfp@OEBPS/audintro.htmm Introduction to Oracle Fusion Middleware Audit Framework

12 Introduction to Oracle Fusion Middleware Audit Framework

In Oracle Fusion Middleware 11g Release 1 (11.1.1), auditing provides a measure of accountability and answers the "who has done what and when" types of questions. This chapter introduces auditing in Oracle Fusion Middleware. It contains the following topics:

12.1 Benefits and Features of the Oracle Fusion Middleware Audit Framework

This section contains these topics:

12.1.1 Objectives of Auditing

With compliance becoming an integral part of any business requirement, audit support is also becoming a focus in enterprise deployments. Customers are looking for application vendors to provide out-of-the-box audit support. In addition, middleware customers who are deploying custom applications would like to centralize the auditing of their deployed applications wherever audit is appropriate.

IT organizations are looking for several key audit features driven by compliance, monitoring, and analytics requirements.

Compliance

Compliance is obviously a major requirement in the enterprise. With regulations such as Sarbanes-Oxley (financial) and Health Insurance Portability and Accountability Act (healthcare), many customers must now be able to audit on identity information and user access on applications and devices. These include events like:

  • User profile change

  • Access rights changes

  • User access activity

  • Operational activities like starting and stopping applications, upgrades, and backups

This allows compliance officers to perform periodic reviews of compliance policies.

Monitoring

The audit data naturally provides a rich set of data for monitoring purpose. In addition to any log data and component metrics that are exposed, audit data can be used to create dashboards and to build Key Performance Indicators (KPIs) for alerts to monitor the health of the various systems on an ongoing basis.

Analytics

Audit data can also be used in assessing the efficacy of controls through analysis on the audit data. The data can also be used for risk analysis. Based on historical data, a risk score can be calculated and assigned to any user. Any runtime evaluation of user access can include the various risk scores as additional criteria to protect access to the systems.

12.1.2 Today's Audit Challenges

To satisfy the audit requirements, IT organizations often battle with the deficiencies in audit support for their deployed applications. There is no reliable standard for:

  • Audit Record Generation

  • Audit Record Format and Storage

  • Audit Policy Definition

As a result, today's audit solutions suffer from a number of key drawbacks:

  • There is no centralized audit framework.

  • The quality of audit support is inconsistent from application to application.

  • Audit data is scattered across the enterprise.

  • Complex data correlation is required before any meaningful cross-component analysis can be conducted.

  • Audit policies and their configurations are also scattered.

These factors are costing IT organization considerable amount of time and resources to build and maintain any reasonable audit solutions. With the data scattered among individual silos, and the lack of consistency and centralization, the audit solutions also tend to be fragile with idiosyncrasies among applications from different vendors with their current audit capabilities.

12.2 Overview of Audit Features

Key features of the Oracle Fusion Middleware Audit Framework include:

12.3 Oracle Fusion Middleware Audit Framework Concepts

This section introduces basic concepts of the Oracle Fusion Middleware Audit Framework:

12.3.1 Audit Architecture

The Oracle Fusion Middleware Audit Framework consists of the following key components:

  • Audit APIs

    These are APIs provided by the audit framework for any audit-aware components integrating with the Oracle Fusion Middleware Audit Framework. During runtime, applications may call these APIs where appropriate to audit the necessary information about a particular event happening in the application code. The interface allows applications to specify event details such as username and other attributes needed to provide the context of the event being audited.

  • The audit framework provides these APIs:

    • audit service API

    • audit client API

  • Audit Events and Configuration

    The Oracle Fusion Middleware Audit Framework provides a set of generic events for convenient mapping to application audit events. Some of these include common events such as authentication. The framework also allows applications to define application-specific events.

    These event definitions and configurations are implemented as part of the audit service in Oracle Platform Security Services. Configurations can be updated through Enterprise Manager (UI) and WLST (command-line tool)

  • The Audit Bus-stop

    Bus-stops are local files containing audit data records before they are pushed to the audit data store. In the event that no audit data store is configured, audit data remains in these bus-stop files. The bus-stop files are simple text files that can be queried easily to look up specific audit events. When an audit data store is in place, the bus-stop acts as an intermediary between the component and the audit data store. The local files are periodically uploaded to the audit data store based on a configurable time interval.

    A key advantage of the audit data store is that audit data from multiple components can be correlated and combined in reports, for example, authentication failures in all middleware components, instances and so on.

  • Audit Loader

    As its name implies, the audit loader loads audit data from the audit bus-stop into the audit data store, if one is configured. For Java component auditing, the audit loader is is a startup class that is started as part of the container start-up. For system components, the audit loader is a periodically spawned process that is invoked by OPMN.

  • Audit Data Store

    The audit data store is a database that contains a pre-defined Oracle Fusion Middleware Audit Framework schema, created by Repository Creation Utility (RCU). Once configured, all the audit loaders are aware of the audit data store and upload data to it periodically. The audit data in the store is expected to be cumulative and will grow overtime. Ideally, this should not be an operational database used by any other applications - rather, it should be a standalone RDBMS used for audit purposes only.

    The audit database can store audit events generated by Oracle components as well as user applications integrated with the audit framework.

  • Audit Metadata Store

    The audit metadata store contains audit event definitions for components and applications.

  • Audit Configuration Mbeans

    All audit configuration is managed through audit configuration MBeans. For Java components and applications, these MBeans are present in the domain administration server and the audit configuration is centrally managed. For system components, separate MBean instances are present for every component instance. Enterprise Manager UI and command-line tools manage Audit configuration using these MBeans.

  • Oracle Business Intelligence Publisher

    The data in the audit data store is exposed through pre-defined reports in Oracle Business Intelligence Publisher. The reports allow users to drill down the audit data based on various criteria. For example:

    • Username

    • Time Range

    • Application Type

    • Execution Context Identifier (ECID)

    You can also use Oracle Business Intelligence Publisher to create your own audit reports.

Audit Flow

The process can be illustrated by looking at the actions taken in the framework when an auditable event (say, login) occurs within an application server instance:


Note:

The architecture shown in Figure 12-1 contains an audit data store; if your site did not configure an audit data store, the audit records reside in the bus-stop files.

  1. During application deployment or audit service start-up, a client such as a Java EE application or Oracle component registers with the audit service.

  2. The service reads the application's pre-configured audit definition file and updates the metadata store with the audit definitions.

  3. When a user accesses the component or application, an audit API function is called to audit the event.

  4. The audit framework checks if events of this type, status, and with certain attributes need to be audited.

  5. If so, the audit function is invoked to create the audit event structure and collect event information like the status, initiator, resource, ECID, and so on.

  6. The event is stored on a local file in an intermediate location known as the bus-stop; each component has its own bus-stop.

  7. If a database is configured for an audit store, the audit loader pulls the events from the bus-stops, uses the application's metadata to format the data, and moves the data to the audit store.

  8. Reports can also be generated from the audit data using Oracle BI Publisher. A set of pre-defined reports are available. (See Chapter 14, "Using Audit Analysis and Reporting".)

Application Behavior in Case of Audit Failure

It is important to note that an application does not stop execution if it is unable to record an audit event for any reason.

12.3.2 Key Technical Concepts

This section introduces key concepts in the Oracle Fusion Middleware Audit Framework.

Audit-Aware Components

The term "audit-aware" refers to components that are integrated with the Oracle Fusion Middleware Audit Framework so that audit policies can be configured and events can be audited for those components. Oracle Internet Directory is an example of an audit-aware component.

Stand-alone applications can integrate with the Oracle Fusion Middleware Audit Framework through configuration with the jps-config.xml file. For details, see see Chapter 28.

Audit Metadata Store

The audit metadata store contains audit event definitions for components as well as applications integrated with the audit framework.

Audit Data Store

The audit data store is the repository for audit event data.


Note:

The metadata store is separate from the audit data store.

Audit Loader

The Audit Loader is a module of the Oracle WebLogic Server instance and provides process control for that instance. The audit loader is responsible for collecting the audit records for all components running in that instance and loading them to the audit data store.

Audit Policy

An audit policy is a declaration of the type of events to be captured by the audit framework for a particular component. For Java components, the audit policy is defined at the domain level. For system components, the audit policy is managed at the component instance level.

Oracle Fusion Middleware Audit Framework provides several pre-defined policy types:

  • None

  • Low (audits fewer events, definition is component-dependent)

  • Medium (audits many events, definition is component-dependent)

  • Custom (implements filters to narrow the scope of audited events)

Audit Policy Component Type

This refers to the component type to be audited; for example, Oracle Internet Directory is a source of auditable events during authentication.

For lists of the events that can be audited for each component, see Section C.1, "Audit Events".

Event Filters

Certain audit events implement filters to control when the event is logged. For example, a successful login event for the Oracle Internet Directory component may be filtered for specific users.

For details, see Section 13.3, "Managing Audit Policies".

Oracle Platform Security Services

Oracle Platform Security Services, a key component of the Oracle Fusion Middleware 11g, is the Oracle Fusion Middleware security implementation for Java features such as Java Authentication and Authorization Service (JAAS) and Java EE security.

For more information about OPSS, see Section 1.1, "What is Oracle Platform Security Services?".

12.3.4 Audit Data Storage

As shown in Figure 12-1, audit data can reside in two types of storage:

  • bus-stop files for intermediate storage of audit data. Each component instance writes to its own bus-stop.

    Bus-stop files are the default out-of-the-box storage mechanism for audit records:

    • For Java components, there is one bus-stop for each Oracle WebLogic Server instance. Audit records generated for all Java EE components running in a given Oracle WebLogic Server instance are stored in the same bus-stop.

    • For system components, there is a separate bus-stop for each component; thus, for example, each instance of Oracle Internet Directory has its own bus-stop.

    Bus-stop files are text-based and easy to query. For further details, see Section 12.3.1, "Audit Architecture"

  • permanent storage in a database; this is known as the audit data store.

    If using a database, audit records generated by all components in all Oracle Fusion Middleware 11g instances in the domain are stored in the same store. You must use an audit data store to utilize Oracle Business Intelligence Publisher reports.

You can move from file-based storage to an audit data store. This requires a specific configuration procedure. See Section 13.2.3, "Configure a Database Audit Data Store for Java Components" for details.

Advantages of Using a Database Store

Having the audit records in the bus-stop files has some practical limitations:

  • you cannot view domain-level audit data

  • reports cannot be run on Oracle BI Publisher

Thus, there are certain advantages to using a database audit data store:

  • You can use Oracle Business Intelligence Publisher for reporting.

  • The database store centralizes records from all components in the domain, whereas the bus-stop stores audit records on a per-instance basis.

  • performance may be improved compared to file-based storage

For these reasons, Oracle recommends that customers switch to a database store for enhanced auditing capabilities.

PKImmPKfp@OEBPS/underjps.htmX9 Introduction to Oracle Platform Security Services

1 Introduction to Oracle Platform Security Services

Oracle Platform Security Services (OPSS) is a security platform that can be used to secure applications deployed in any of the supported platforms or in standalone applications. This chapter introduces the main features of this platform in the following sections:

The scope of this document does not include Oracle Web Services security. For details about that topic, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

For an overview of Oracle Fusion Middleware security topics, see Oracle Fusion Middleware Security Overview.

1.1 What is Oracle Platform Security Services?

OPSS provides enterprise product development teams, systems integrators, and independent software vendors with a standards-based, portable, integrated, enterprise-grade security framework for Java SE and Java EE applications.

OPSS is the underlying security platform that provides security to Oracle Fusion Middleware including WebLogic Server, Server Oriented Architecture (SOA) applications, Oracle WebCenter, Oracle Application Development Framework (ADF) applications, and Oracle Entitlement Server. OPSS is designed to be portable to third-party application servers, so developers can use OPSS as the single security framework for both Oracle and third-party environments, thus decreasing application development, administration, and maintenance costs.

OPSS provides an abstraction layer in the form of application programming interfaces (APIs) that insulate developers from security and identity management implementation details. With OPSS, developers do not need to know the details of, for example, cryptographic key management, repository interfaces, or other identity management infrastructures. Using OPSS, in-house developed applications, third-party applications, and integrated applications benefit from the same, uniform security, identity management, and audit services across the enterprise.

For OPSS-related news, including FAQs, a whitepaper, and code examples, and forum discussions, see http://www.oracle.com/technology/products/id_mgmt/opss/index.html.

1.2 OPSS Architecture Overview

OPSS comprises the application server's security and Oracle's Fusion Middleware security. Figure 1-1 illustrates the layered architecture that combines these two security frameworks:

The top layer includes the OPSS security services; the next layer includes the service providers, and the bottom layer includes the OPSS security store with a repository of one of three kinds.

Security Services Providers

Security Services Provider Interface (SSPI) provides Java EE container security in permission-based (JACC) mode and in resource-based (non-JACC) mode, and resource-based authorization for the environment.

SSPI is a set of APIs for implementing pluggable security providers. A module implementing any of these interfaces can be plugged into SSPI to provide a particular type of security service, such as custom authentication or a particular role mapping.

For details, see section The Security Service Provider Interfaces (SSPIs) in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.

Oracle Platform Security Services

Java Authorization (JAZN) functionality includes the Credential Store Framework (CSF), the Common Audit Framework (CAF), Keystore Service, and other components, and combined with SSPI as Oracle Platform Security Services (OPSS).

1.2.1 Benefits of Using OPSS

The benefits that OPSS offers include the following:

  • Allows developers to focus on application and domain problems

  • Supports enterprise deployments

  • Supports several LDAP servers and SSO systems

  • Is certified on the Oracle WebLogic Server

  • Pre-integrates with Oracle products and technologies

  • Offers a consistent security experience for developers and administrators

  • Provides a uniform set of APIs for all types of applications

  • Optimizes development time by offering abstraction layers (declarative APIs)

  • Provides a simplified application security maintenance

  • Allows changing security rules without affecting application code

  • Eases the administrator's job

  • Integrates with identity management systems

  • Integrates with legacy and third-party security providers

OPSS combines SSPI and JPS to provide a framework where the application server and Oracle applications can seamlessly run in a single environment.

OPSS supports security for Java EE applications and for Oracle Fusion Middleware applications, such as Oracle WebCenter and Oracle SOA Suite.

Developers can use OPSS APIs to secure all types of applications and integrate them with other security artifacts, such as LDAP servers, RDBMS, and custom security components.

Administrators can use OPSS to deploy large enterprise applications with a small, uniform set of tools and administer all security in them. OPSS simplifies the maintenance of application security because it allows the modification of security configuration without changing the application code.

By default and out-of-the-box, Oracle WebLogic Server stores users and groups in its embedded LDAP repository. Domains can be configured, however, to use identity data in other kinds of LDAP repositories, such as Oracle Internet Directory, ActiveDirectory, Novell eDirectory, and OpenLDAP. In addition, Oracle WebLogic Server provides a generic, default LDAP authenticator that can be used with other LDAP servers not in the preceding list.

Out-of-the-box, policies and credentials are stored in file-based stores; these stores can be moved (or reassociated) to an LDAP repository backed by an Oracle Internet Directory.

Out-of-the-box, keys and certificates are stored in a file-based keystore, which can be reassociated with a database or an LDAP repository.


Note:

This guide does not attempt to describe in detail WebLogic security features; wherever specific information about SSPI is used or assumed, the reader is referred to the appropriate document.

1.3 Oracle ADF Security Overview

Oracle ADF is an end-to-end Java EE framework that simplifies development by providing out-of-the-box infrastructure services and a visual and declarative development experience.

Oracle ADF Security is based on the JAAS security model, and it uses OPSS. Oracle ADF Security supports LDAP- or file-based policy and credential stores, uses permission-based fine-grained authorization provided by OPSS, and simplifies the configuration of application security with the aid of visual declarative editors and the Oracle ADF Security wizard, all of them available in Oracle JDeveloper 11g (any reference to this tool in this guide stands for its 11g release).

Oracle ADF Security authorization allows protecting components (flows and pages), is integrated with Oracle JDeveloper at design time, and is available at run time when the application is deployed to the integrated server where testing of security features is typically carried out.

During the development of an Oracle ADF application, the authenticators are configured with the Oracle WebLogic Server Administration Console for the particular domain where the application is deployed, and the policy store is file-based and stored in the file jazn-data.xml. For deployment details, see Section 6.3.1, "Deploying to a Test Environment."

To summarize, Oracle ADF Security provides:

For related information, see Scenario 2: Securing an Oracle ADF Application.

1.4 OPSS for Administrators

Depending on the application type, the guidelines to administer application security with Oracle WebLogic Administration Console, OPSS scripts, Fusion Middleware Control, or Oracle Entitlements Server are as follows:

  • For Java EE applications, security is managed with Oracle WebLogic Administration Console, Oracle Entitlements Server, or OPSS scripts.

  • For Oracle SOA, Oracle WebCenter, MDS, and Oracle ADF applications, authentication is managed with Oracle WebLogic Administration Console and authorization is managed with Fusion Middleware Control and Oracle Entitlements Server.

  • For Java EE applications integrating with OPSS, authentication is managed using Oracle WebLogic Administration Console, and authorization is managed with Fusion Middleware Control and Oracle Entitlements Server.

For details about security administration, see Chapter 5, "Security Administration."

1.5 OPSS for Developers

This section summarizes the main OPSS features typically used when securing applications, in the following scenarios:

For other use cases, see Section 19.2, "Security Integration Use Cases."

1.5.2 Scenario 2: Securing an Oracle ADF Application

Oracle Application Development Framework (ADF) is a Java EE development framework available in Oracle JDeveloper that simplifies the development of Java EE applications by minimizing the need to write code that implements the application's infrastructure, thus allowing developers to focus on the application features. Oracle ADF provides these infrastructure implementations as part of the Oracle JDeveloper framework, therefore enhancing the development experience with visual and declarative approaches to Java EE development.

Oracle ADF implicitly uses OPSS, and, for most part, the developer does not have to code directly to OPSS APIs; of course, the developer can nevertheless use direct calls to OPSS APIs.

Oracle ADF leverages container authentication and subsequently uses JAAS based authorization to control access to Oracle ADF resources. These authorization policies may include application-specific roles and JAAS authorization permissions. Oracle ADF connection credentials are stored securely in the credential store.

Oracle ADF and Oracle WebCenter applications deployed on Oracle WebLogic Server include WebLogic authenticators, such as the default WebLogic authenticator, and may include a single sign-on solution (Oracle Access Manager or Oracle Application Server Single Sign-On).

Usually, applications also use one or several of the following OPSS features: anonymous and authenticated role support, policy management APIs, and the Credential Store Framework.

For details about these topics, see the following sections:

For details on how to develop and secure Oracle ADF applications, see chapter 29 in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.

1.5.3 Scenario 3: Securing a Java SE Application

Most of the OPSS features that work in Java EE applications work in Java SE applications, but there are some differences, which are noted in this section.

Configuration

All OPSS-related configuration and data files are located under configuration directory in the domain home. For example, the configuration file for a Java SE environment is defined in the file jps-config-jse.xml by default installed in the following location:

$DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml

To specify a different location, use the following switch:

-Doracle.security.jps.config=pathToConfigFile

The syntax of this file is identical to that of the file jps-config.xml. This file is used by code running in WebLogic containers. For details, see Appendix A, "OPSS Configuration File Reference."

For details about security configuration for Java SE applications, see Section 22.2, "Authentication for Java SE Applications," and Section 23.1, "Configuring Policy and Credential Stores in Java SE Applications."

Required JAR in Class Path

To make OPSS services available to a Java SE application, ensure that the following JAR file is added to your class path, located in the modules area of the Oracle installation home:

$ORACLE_HOME/oracle_common/modules/oracle.jps_11.1.1/jps-manifest.jar

Login Modules

Java SE applications can use standard JAAS login modules. However, to use the same login module on WLS, implement a custom authentication provider that invokes the login module. The SSPI interfaces allow integrating custom authentication providers in WLS.

The login module recommended for Java SE applications is the IdentityStore login module.

For details, see section Authentication Providers in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.

PKXXXPKfp@ OEBPS/toc.ncxj& Oracle® Fusion Middleware Application Security Guide, 11g Release 1 (11.1.1) Cover Table of Contents List of Examples List of Figures List of Tables Oracle Fusion Middleware Application Security Guide, 11g Release 1 (11.1.1) Preface What's New in This Guide Understanding Security Concepts Introduction to Oracle Platform Security Services Understanding Users and Roles Understanding Identities, Policies, Credentials, Keys, and Certificates About Oracle Platform Security Services Scenarios Basic OPSS Administration Security Administration Deploying Secure Applications Advanced OPSS Administration Configuring the Identity Store Service Configuring the OPSS Security Store Managing the Policy Store Managing the Credential Store Managing Keys and Certificates with the Keystore Service Introduction to Oracle Fusion Middleware Audit Framework Configuring and Managing Auditing Using Audit Analysis and Reporting Single Sign-On Configuration Introduction to Single Sign-On in Oracle Fusion Middleware Configuring Single Sign-On with Oracle Access Manager 11g Configuring Single Sign-On Using Oracle Access Manager 10g Configuring Single Sign-On using OracleAS SSO 10g Developing with Oracle Platform Security Services APIs Integrating Application Security with OPSS The OPSS Policy Model Manually Configuring Java EE Applications to Use OPSS Authentication for Java SE Applicaitons Authorization for Java SE Applications Developing with the Credential Store Framework Developing with the User and Role API Developing with the Identity Directory API Developing with the Keystore Service Developing with the Audit Service Appendices OPSS Configuration File Reference File-Based Identity and Policy Store Reference Oracle Fusion Middleware Audit Framework Reference User and Role API Reference Administration with WLST Scripting and MBean Programming OPSS System and Configuration Properties Upgrading Security Data References OPSS Scripts Using an OpenLDAP Identity Store Adapter Configuration for Identity Virtualization Troubleshooting Security in Oracle Fusion Middleware Index Copyright PKo&j&PKfp@OEBPS/part_gs.htm4 Basic OPSS Administration

Part II

Basic OPSS Administration

This part describes basic OPSS administration features in the following chapters:

PKp߸PKfp@OEBPS/cover.htm  Cover

Oracle Corporation

PK*  PKfp@OEBPS/stores.htm X Understanding Identities, Policies, Credentials, Keys, and Certificates

3 Understanding Identities, Policies, Credentials, Keys, and Certificates

Applications use the identity, policy, credential stores and keystores configured in the domain in which they run. This chapter introduces the basic concepts regarding identity, policy, credential, and keystore data, and it is divided into the following sections:

For definitions of the terms used in this chapter, see Section 2.1, "Terminology."

For scenarios illustrating the use of stores, see Chapter 4, "About Oracle Platform Security Services Scenarios."

3.1 Authentication Basics

OPSS uses server authentication providers, components that validate user credentials or system processes based on a user name-password combination or a digital certificate. Authentication providers also make user identity information available to other components in a domain (through subjects) when needed.

Java EE applications must use LDAP-based authentication providers; Java SE applications use file-based identity stores out-of-the-box, but the identity store can be configured to be LDAP-based.

For further details, see section Authentication in Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server.


Note:

OPSS does not support automatic migration of users and groups used in application development to a remote WebLogic Server where an application may be deployed. Instead, one must independently create the necessary application identities using the Oracle WebLogic Administration Console, OPSS scripts, or the appropriate tool depending on the authentication provider(s) configured in your domain.

This section covers the following topics:

3.1.2 Oracle WebLogic Authenticators

For a list of WebLogic authenticator providers, see chapter 4, Authentication Providers in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server.

For details about the available authenticators, and choosing and configuring one, see section Configuring Authentication Providers in Oracle Fusion Middleware Securing Oracle WebLogic Server, and section Configure Authentication and Identity Assertion providers in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.

By default and out-of-the-box, Oracle WebLogic Server stores users and groups in the DefaultAuthenticator. This authenticator is setup to use cn as the default attribute.

The data stored in any LDAP authenticator can be accessed by the User and Role API to query user profile attributes. For details about WebLogic LDAP authenticators, see the following sections:


Important:

If your domain uses the DefaultAuthenticator, then the domain administration server must be running for an application to query data using the User and Role API.

OPSS requires that a domain have at least one LDAP-based authenticator configured in a domain.


For details about X.509 identity assertion, see section How an LDAP X509 Identity Assertion Provider Works in Oracle Fusion Middleware Securing Oracle WebLogic Server.

For details about authentication using the SAML 1.1 or SAML 2.0 identity assertion provider, see section Configuring the SAML Authentication Provider in Oracle Fusion Middleware Securing Oracle WebLogic Server.

3.1.2.1 Using an LDAP Authenticator

Oracle WebLogic Server offers several LDAP-based authenticators. For a choice of available LDAP servers for the identity store, see Supported LDAP Identity Store Types. The Weblogic DefaultAuthenticator is the default authenticator configured and ready to use out-of-the-box after installation. Other authenticators can be configured using the WebLogic Administration Console.

For details about the use of authenticators in Java SE applications, see Section 22.2.2, "Configuring an LDAP Identity Store in Java SE Applications."

3.1.2.2 Configuring the LDAP Identity Store Service

Oracle WebLogic Server allows the configuration of multiple authenticators in a given context, each of which has a control flag set. One of them must be an LDAP-based authenticator.

OPSS initializes the identity store service with the LDAP authenticator chosen from the list of configured LDAP authenticators according to the following algorithm:

  1. Consider the subset of LDAP authenticators configured. Note that, since the context is assumed to contain at least one LDAP authenticator, this subset is not empty.

  2. Within that subset, consider those that have set the maximum flag. The flag ordering used to compute this subset is the following:

    REQUIRED > REQUISITE > SUFFICIENT > OPTIONAL
    

    Again, this subset (of LDAPs realizing the maximum flag) is not empty.

  3. Within that subset, consider the first configured in the context.

The LDAP authenticator singled out in step 3 is the one chosen to initialize the identity store service. For details about host name verification when establishing an SSL connection with an LDAP authenticator, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

For details about the default values that OPPS uses to initialize the various supported LDAP authenticators, see javadoc User and Role API documentation in Section H.1, "OPSS API References." If a service instance initialization value is provided by default and also (explicitly) in the service instance configuration, the value configured takes precedence over the default one.


Important:

Any LDAP-based authenticator used in a domain, other than the DefaultAuthenticator, requires that the flag UseRetrievedUserNameAsPrincipal be set. Out-of-the-box, this flag is set in the DefaultAuthenticator.

3.2 Policy Store Basics

A Java 2 policy specifies the permissions granted to signed code loaded from a given location.

A JAAS policy extends Java 2 grants by allowing an optional list of principals; the semantics of the permissions are granted to only code from a given location, possibly signed, and run by a user represented by those principals.

JACC extends the Java 2 and JAAS permission-based policy to EJBs and Servlets by defining an interface to plug custom authorization providers, that is, pluggable components that allow the control and customizing of authorizations granted to running Java EE applications.

An application policy is a collection of Java 2 and JAAS policies, which is applicable to just that application (in contrast to a Java 2 policy, which are applicable to the whole JVM).

The policy store is a repository of system and application-specific policies and roles. Application roles can include enterprise users and groups specific to the application (such as administrative roles). A policy can use any of these groups or users as principals.

In the case of applications that manage their own roles, Java EE application roles (configured in files web.xml or ejb-jar.xml) get mapped to enterprise users and groups and used by application-specific policies.


Important:

As long as a domain is pointing to a policy store, that policy store cannot be deleted from the environment.

Policy Store Types

A policy store can be file-, LDAP-, or DB-based. A file-based policy store is an XML file, and this store is the out-of-the-box policy store provider. The only LDAP-based policy store type supported is Oracle Internet Directory. The only DB-based policy store type supported is Oracle RDBMS (releases 10.2.0.4 or later; releases 11.1.0.7 or later; and releases 11.2.0.1 or later).

Policy Store Scope, Migration, and Reassociation

There is exactly one policy store per domain. During development, application policies are file-based and specified in the file jazn-data.xml.

When the application is deployed on WebLogic with Fusion Middleware Control, they can be automatically migrated into the policy store. For details about this feature, see Section 8.6.1, "Migrating with Fusion Middleware Control." By default, the policy store is file-based.

When the application is deployed on WebSphere, the behavior of migration at deployment can be manually specified as described in Section 21.4.1, "Parameters Controlling Policy Migration," and Section 21.4.4, "Parameters Controlling Credential Migration."

For reassociation details, see Section 8.5, "Reassociating the OPSS Security Store."

For details about the resource catalog support within a policy store, see Section 20.3.1, "The Resource Catalog."

3.3 Credential Store Basics

A credential store is a repository of security data (credentials) that certify the authority of users, Java components, and system components. A credential can hold user name and password combinations, tickets, or public key certificates. This data is used during authentication, when principals are populated in subjects, and, further, during authorization, when determining what actions the subject can perform.

OPSS provides the Credential Store Framework, a set of APIs that applications can use to create, read, update, and manage credentials securely.

Credential Store Types

A credential store can be file-, LDAP-, or DB-based. A file-based credential store, also referred to as wallet-based and represented by the file cwallet.sso, is the out-of-the-box credential store. The only LDAP-based credential store type supported is Oracle Internet Directory. The only DB-based credential store type supported is Oracle RDBMS (releases 10.2.0.4 or later; releases 11.1.0.7 or later; and releases 11.2.0.1 or later).

Credential Store Scope, Migration, and Reassociation

An application can use either the domain credential store or its own wallet-based credential store. The domain credential store can be wallet-based (by default), LDAP-, or DB-based. The only LDAP-based credential store type supported is Oracle Internet Directory.

The migration of application credentials to the credential store can be configured to take place automatically when the application is deployed. For details, see Section 8.6.1, "Migrating with Fusion Middleware Control."

Credentials can also be reassociated from one type of store to another. For details, see Section 8.5, "Reassociating the OPSS Security Store."

3.4 Keystore Service Basics

The Keystore Service provides a central repository for keystores and trust stores containing all the keys and certificates used by a domain's components and applications. This eliminates the need to associate keystores with individual applications.

The administrator works with a single user interface providing a unified way to view and manage all keystores.

PKX XPKfp@OEBPS/introroles.htm Understanding Users and Roles

2 Understanding Users and Roles

This chapter describes various characteristics of users and roles, such as the anonymous role, the authenticated role, role mapping, and the role category. It also includes the definition of terms used throughout this guide and an overview of the User and Role API Framework.

OPSS delegates authentication to Oracle WebLogic Server authenticator providers managed with the WebLogic Administration Console.

This chapter is divided into the following sections:

For further details about managing users and roles programmatically, see Chapter 25, "Developing with the User and Role API."

2.1 Terminology

This section definies most of the OPSS security terms.

Users

A user, or enterprise user, is an end-user accessing a service. User information is stored in the identity store. An authenticated user is a user whose credentials have been validated.

An anonymous user is a user whose credentials have not been validated (hence unauthenticated) that is permitted access to only unprotected resources. This user is specific to OPSS and its use can be enabled or disabled by an application. For details about anonymous user support, see Section 2.4, "The Anonymous User and Role."

Roles

An enterprise role or enterprise group is a collection of users and other groups. It can be hierarchical, that is, a group can include arbitrarily nested groups (other than itself).

A Java EE logical role is a role specified declaratively or programmatically by a Java EE application. It is defined in an application deployment descriptor and, typically, used in the application code. It can be mapped to only enterprise groups or users, and it cannot be mapped directly to application roles.

An application role is a collection of users, groups, and other application roles; it can be hierarchical. Application roles are defined by application policies and not necessarily known to a Java EE container. Application roles can be many-to-many mapped to external roles. For example, the external group employee (stored in the identity store) can be mapped to the application role helpdesk service request (in one stripe) and to the application role self service HR (in another stripe).

For details about the anonymous role, see Section 2.4, "The Anonymous User and Role." For details about the authenticated role, see Section 2.3, "The Authenticated Role."

Principal

A principal is the identity to which the authorization in the policy is granted. A principal can be a user, an external role, or an application role. Most frequently, it is an application role.

Application Policy

An application policy is a functional policy that specifies a set of permissions that an entity (the grantee, a principal or code source) is allowed within an application, such as viewing web pages or modifying reports. That is, it specifies who can do what in an application.

An application policy uses:

Figure 2-1 illustrates the application policy model.

OPSS Subject

An OPSS subject is a collection of principals and, possibly, user credentials such as passwords or cryptographic keys. The server authentication populates the subject with users and groups, and then augments the subject with application roles. The OPSS Subject is key in identity propagation using other Oracle Identity Management products such as OAM, for example. For details about how anonymous data is handled, see Section 2.4.1, "Anonymous Support and Subject."

Security Stores

The identity store is the repository of enterprise users and groups and must be LDAP-based. Out-of-the-box the identity store is the WebLogic LDAP DefaultAuthenticator. Other types of identity stores include Oracle Internet Directory, Sun Directory Server, and Oracle Virtual Directory.

The policy store is the repository of application and system policies. This store is administered with Oracle Enterprise Manager Fusion Middleware Control.

The credential store is the repository of credentials. This store is administered with Oracle Enterprise Manager Fusion Middleware Control.

The OPSS security store is the logical repository of system and application-specific policies, credentials, and keys. The only type of LDAP-based OPSS security store supported is Oracle Internet Directory.

For details, see Chapter 3, "Understanding Identities, Policies, Credentials, Keys, and Certificates."

Other Terms

A system component is a manageable process that is not a WebLogic component. Examples include Oracle Internet Directory, WebCache, and Java SE components.

A Java component is a peer of a system component, but managed by an application server container. Generally it refers to a collection of applications and resources in one-to-one relationship with a domain extension template. Examples include Oracle SOA applications, Oracle WebCenter Spaces.

2.2 Role Mapping

OPSS supports many-to-many mapping of application roles in the policy store to enterprise groups in the identity store, which allows users in enterprise groups to access application resources as specified by application roles. Since this mapping is many-to-many, it is alternatively referred to as the role-to-group mapping or as the group-to-role mapping.


Notes:

Oracle JDeveloper allows specifying this mapping when the application is being developed in that environment. Alternatively, the mapping can be also specified, after the application has been deployed, using OPSS scripts, Fusion Middleware Control, or Oracle Entitlements Server, as explained in Section 9.2.2, "Managing Application Roles."

The mapping of an application role to an enterprise group rewrites the privilege of the enterprise group as the union of its privileges and those of the mapped application role. Therefore, it (possibly) augments the privileges of the enterprise group but never removes any from it.


2.2.1 Permission Inheritance and the Role Hierarchy

OPSS roles can be structured hierarchically by the relation “is a member of.” Thus a role can have as members users or other roles.


Important:

When building a role hierarchy, ensure that you do not introduce circular dependencies to prevent unwanted behavior. For example, setting roleA to be a member of roleB, and roleB to be a member of roleA would create such a circular dependency.

In a role hierarchy, role members inherit permissions from the parent role. Thus, if roleA is a member of roleB, then all permissions granted to roleB are also permissions granted to roleA. Of course, roleA may have its own particular permissions, but, just by being a member of roleB, roleA inherits all the permissions granted to roleB.

For details about managing an application role hierarchy with OPSS scripts, see Section 9.3.4, "grantAppRole," and Section 9.3.5, "revokeAppRole."

For details about managing an application role hierarchy with Oracle Entitlements Server, see Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

The following example illustrates a role hierarchy consisting of the following nested application users and roles:

  • The role developerAppRole has the following members:

    developer
    developer_group
    managerAppRole
    directorAppRole
    
  • In addition, the role directorAppRole has the following members:

    developer
    developer_group
    

Here is the relevant portions of the file jazn-data.xml specifying the above hierarchy:

<policy-store>
  <applications>
    <application>
      <name>MyApp</name>
      <app-roles>
        <app-role>
          <name>developerAppRole</name>
          <class>oracle.security.jps.service.policystore.ApplicationRole</class>
          <display-name>Application developer role</display-name>
          <description>Application developer role</description>
          <guid>61FD29C0D47E11DABF9BA765378CF9F5</guid>
          <members>
            <member>
                      <class>weblogic.security.principal.WLSUserImpl</class>
                      <name>developer</name>
            </member>
            <member>
                      <class>weblogic.security.principal.WLSGroupImpl</class>
                      <name>developer_group</name>
            </membe>
            <member>
              <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
              <name>managerAppRole</name>
            </member>
          </members>
        </app-role>
        <app-role>
                          <name>directorAppRole</name>
                          <class>oracle.security.jps.service.policystore.ApplicationRole</class>
                          <display-name>Application director role </display-name>
                          <description>Application director role</description>
                          <guid>61FD29C0D47E11DABF9BA765378CF9F8</guid>
                          <members>
            <member>
                                      <class>weblogic.security.principal.WLSUserImpl</class>
                                      <name>developer</name>
            </member>
            <member>
                                        <class>weblogic.security.principal.WLSGroupImpl</class>
                                        <name>developer_group</name>
            </member>
                                   </members>
         </app-role> ...
       </app-roles>
 
      <jazn-policy>
        <grant>
          <grantee>
             <principals>
                <principal>
                   <class>
           oracle.security.jps.service.policystore.ApplicationRole</class>
                   <name>developerAppRole</name>
                </principal>
             </principals>
          </grantee>
          <permissions>
            <permission>
              <class>java.io.FilePermission</class>
              <name>/tmp/oracle.txt</name>
              <actions>write</actions>
             </permission>
           </permissions>
         </grant>

         <grant>
           <grantee>
             <principals>
               <principal>
                 <class>
           oracle.security.jps.service.policystore.ApplicationRole</class>
                 <name>managerAppRole</name>
               </principal>
             </principals>
           </grantee>
           <permissions>
             <permission>
               <class>java.util.PropertyPermission</class>
               <name>myProperty</name>
               <actions>read</actions>
             </permission>
            </permissions>

           </grant>
           <grant>
             <grantee>
               <principals>
                 <principal>
                   <class>
oracle.security.jps.service.policystore.ApplicationRole</class>
                   <name>directorAppRole</name>
                 </principal>
               </principals>
             </grantee>
             <permissions>
               <permission>
                 <class>foo.CustomPermission</class>
                 <name>myProperty</name>
                 <actions>*</actions>
               </permission>
             </permissions>
           </grant>
         </jazn-policy>
       </policy-store>

Table 2-1 summarizes the permissions that each of the five users and roles in the above hierarchy gets according the inheritance rule:

2.3 The Authenticated Role

OPSS supports the use of a special role: the authenticated role. This role has the following characteristics:

The permissions granted to the authenticated role need not be specified explicitly but are implicitly derived from the enterprise groups and application roles of which it is a member.

A typical use of the authenticated role is to allow authenticated users access to common application resources, that is, to resources available to a user that has been authenticated.

For details on how an application can manually configure the use of the authenticated role, see Section 21.1, "Configuring the Servlet Filter and the EJB Interceptor."

2.4 The Anonymous User and Role

OPSS supports the use of two special entities: the anonymous user and the anonymous role. Like the authenticated role, these entities need not be declared and applications configure their use in the JpsFilter or JpsInterceptor. Any of them can be used by an application in the application's role hierarchy.

When enabled, before the user is authenticated and while the user is accessing unprotected resources, the user is represented by a subject populated with just the anonymous user and the anonymous role. Eventually, if that subject attempts access to a protected resource, then authorization handles the subject as explained in Anonymous Support and Subject.

The permissions granted to the anonymous user and role need not be specified explicitly but are implicitly derived from the enterprise groups and application roles of which they are a member.

A typical use of the anonymous user and role is to allow unauthenticated users to access public, unprotected resources.

For details on how an application can manually configure the use of the anonymous user and role, see Section 21.1, "Configuring the Servlet Filter and the EJB Interceptor."

2.5 Administrative Users and Roles

A (WebLogic) administrator is any user member of the group Administrators, and any user that exists in a security realm can be added to this group.

For details about the default groups that exist in a security realm, see section Users, Groups, And Security Roles in Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server.

Generally, there is no default name for an administrator, with just one exception: when you install the examples, you get a default user name and password for the administrator of the sample domain. It is recommended, however, that these examples not be used in any production environment.

For details, see section Install WebLogic Server in a Secure Manner in Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server.

Once a domain is configured, users that have been created in the security realm can be added or removed from the Administrators group at anytime by any member of the Administrators group. The two basic tools for managing these accounts are the Oracle WebLogic Administration Console and the Oracle WebLogic Scripting Tool (WLST).

For details, see section Add Users to Groups in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help, and section Using the WebLogic Scripting Tool in Oracle Fusion Middleware Oracle WebLogic Scripting Tool.

2.6 Managing User Accounts

This section provides several links to information about creating user accounts and protecting their passwords.

2.7 Principal Name Comparison Logic

This section explains how principal comparison affects OPSS authorization and describes the system parameters that control the principal name comparison logic, in the following sections:

2.7.2 System Parameters Controlling Principal Name Comparison

The following two WebLogic Server system parameters control the way principal names are compared in a domain and allow, furthermore, to compare principals using DN and GUID data:

PrincipalEqualsCaseInsensitive (True or False; False by default)
PrincipalEqualsCompareDnAndGuid (True or False; False by default)

To set these parameters using the WebLogic Server Console, proceed as follows:

  1. In the left pane of the Console, under Domain FStructure, select the domain for which you intend to set the parameters above.

  2. Select Configuration > Security and click Advanced.

  3. Check (to set to true) or uncheck (to set to false) the box next to the following entries:

    • Principal Equals Case Insensitive

    • Principal Equals Compare DN and GUID

  4. Restart the server. Changes do not take effect until the server is restarted.

These parameters can alternatively be set using OPSS scripts. For more details about configuring the WebLogic server, see section Configuring a Domain to Use JAAS Authorization in Oracle Fusion Middleware Securing Oracle WebLogic Server.

The name comparison logic chosen at runtime is described by the following pseudo-code fragment:

if PrincipalEqualsCompareDnAndGuid is true
//use GUID and DN to compare principals
{
  when GUID is present in both principals {
     use case insensitive to compare GUIDs
  } 
  when DN is present in both principals {
     use case insensitive to compare DNs
  }
}

if PrincipalEqualsCaseInsensitive is true
//use just name to compare principals
{
  use case insensitive to compare principal names
}
else
{
  use case sensitive to compare principal names
}

Since by default both PrincipalEqualsCompareDnAndGuid and PrincipalEqualsCaseInsensitive are false, name principal comparison defaults to case sensitive.

2.8 The Role Category

The role category allows a security administrator to organize application roles. Rather than displaying the flat list of roles in an application, an administrator can organize them arbitrarily in flat sets or categories.

For details about managing an application role category with Oracle Entitlements Server, see Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

The following fragment illustrates the configuration of a role category:

<role-categories>
  <role-category>
    <name>RC_READONLY</name>
    <display-name>RC_READONLY display name</display-name>
    <description>RC_READONLY description</description>
    <members>
      <role-name-ref>AppRole1</role-name-ref>
      <role-name-ref>AppRole2</role-name-ref>
      <role-name-ref>AppRole3</role-name-ref>
    </members>
  </role-category>
</role-categories>

The role category name is case insensitive. The role category can be managed with the interface RoleCategoryManager.

For details about this interface, see the Javadoc document Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services.

PKEPFPKfp@OEBPS/osso_b_oam11g.htm Configuring Single Sign-On with Oracle Access Manager 11g

16 Configuring Single Sign-On with Oracle Access Manager 11g

The chapter provides information on configuring single sign-on using Oracle Access Manager 11g. It includes the following major sections:

16.1 Introduction to Oracle Access Manager 11g SSO

Oracle Access Manager 11g is part of Oracle's enterprise class suite of security products. Intended for use in new and existing SSO deployments, Oracle Access Manager 11g provides a full range of Web perimeter security functions that include Web single sign-on; authentication and authorization; policy administration, and more.

Oracle Access Manager 11g single sign-on (SSO) and single log-out (SLO) supports a variety of application platforms including:

  • SOA

  • WebCenter

Oracle Access Manager 11g supports integration with a variety of applications, as described in the Oracle Fusion Middleware Integration Guide for Oracle Access Manager.

  • Oracle Identity Navigator

  • Oracle Identity Federation

  • Oracle Identity Manager

  • Oracle Adaptive Access Manager

As described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service, Oracle Access Manager 11g differs from Oracle Access Manager 10g in that identity administration features have been transferred to Oracle Identity Manager 11g. This includes user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration.

Console Protection for Oracle Identity Management Applications

Oracle Access Manager 11g and other Oracle Identity Management applications are deployed in a WebLogic container. Individual administration consoles include Oracle Access Manager, Oracle Adaptive Access Manager, Oracle Identity Navigator, Oracle Identity Manager, Oracle WebLogic Server, and Oracle Entitlements Server.

These are protected by default using pre-configured Authentication Providers in the WebLogic Administration Console and a pre-registered IAMSuiteAgent with Oracle Access Manager 11g. OAM 11g SSO policies are pre-seeded. No further configuration is needed for the consoles.

Preview of OAM 11g Deployments

You can configure Oracle Access Manager in a new WebLogic administration domain or in an existing WebLogic administration domain using the Oracle Fusion Middleware Configuration Wizard.

See "Requirements for the Provider with Oracle Access Manager"

Oracle Access Manager 11g provides new server-side components that maintain backward compatibility with new or existing policy-enforcement agents. Dynamic Server-initiated updates are performed for any policy or configuration changes.

Oracle Access Manager 11g provides single sign-on (SSO), authentication, authorization, and other services to registered Agents (in any combination) protecting resources:

You can integrate with Oracle Access Manager 11g, any Web applications currently using Oracle ADF Security and the OPSS SSO Framework.

Only users with sufficient privileges can log in to the Oracle Access Manager Administration Console or use OAM administrative command-line tools. Your enterprise might require independent sets of administrators: one set of users responsible for OAM administration and a different set for WebLogic administration. For more information, see "Defining a New OAM Administrator Role" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Overview of OAM 11g

The following outlines some of the basic features of Oracle Access Manager 11g:

Provisioning/Remote Registration: A new remote registration tool enables administrators inside or outside the network to register agents and policies. A username and password must be set in the primary User Identity Store for OAM 11g.

Authentication: Oracle Access Manager 11g application domains aggregate resources and security policies (one policy per resource). Oracle Access Manager 11g authentication policies include a specific scheme. Supported authentication modules include LDAP, X.509, and Kerberos. Authentication user mapping is performed against the primary user-identity provider by the centralized credential collector.

Authorization: Oracle Access Manager 11g performs authorization based on security policies defined in the application domain and persisted in the database. Authorization policies define the resource and constraint evaluation.

Responses: Administrators can set session attributes using authentication and authorization Responses. Aside from session attributes, a Response can also obtain user-related data and request-related data. Responses, once set, are then sent as either HTTP Headers or Cookies to the agent that helps manifest them. For cookie values and header variables, Responses can retrieve session attributes previously set by another Response. For example, session attributes set by a Response upon authentication can be retrieved as a header value during authorization.

Session Management: Oracle Access Manager 11g session management services track active user sessions through a high performance distributed cache system based on technology from Oracle Coherence. Each Oracle Access Manager runtime instance is a node within the distributed cache system. Secure communication between the nodes is facilitated using a symmetric key. The Oracle Access Manager runtime instances move user session data in the local cache into the distributed cache for other nodes to pick up. Each Oracle Access Manager runtime instance can also configure the replication factor and determine how session data is distributed. Administrators can configure the session lifecycle, locate and remove specific active sessions, and set a limit on the number of concurrent sessions a user can have at any time. Out-of-band session termination prevents unauthorized access to systems when a user has been terminated.

Keys: The Oracle Access Manager 11g runtime is deployed as an application to a WebLogic Managed Server or Cluster. New Oracle Access Manager 11g WebGates support a shared secret per agent trust model. 11g WebGates use agent/host specific cookies, which offers superior security. Oracle Access Manager 11g WebGates are all trusted at the same level; a cookie specific for the WebGate is set and cannot be used to access any other WebGate-protected applications on a user's behalf. Cookie-replay types of attacks are prevented.

SSO and SLO: The Oracle Access Manager 11g Server Session Token forms the basis for SSO between Oracle Access Manager and OSSO Agents. Logout is driven through Oracle Access Manager 11g Server Global Logout, which terminates the central session and logs out the user from each agent that was visited.

  • With Oracle Access Manager 10g WebGates, logout removes the ObSSOCookie and then redirects to the Global Logout page.

  • With Oracle Access Manager 11g WebGates and mod_osso agents, logout redirects to the Global Logout page and each agent is called back to remove the agent-specific cookie.

Logging and Auditing: Oracle Access Manager 11g components use the same logging infrastructure and guidelines as any other component in Oracle Fusion Middleware 11g. Oracle Access Manager 11g provides agent and server monitoring functions. Oracle Access Manager 11g auditing functions are based on the Common Audit Framework; audit-report generation is supported using Oracle Business Intelligence Publisher.

Access Tester: The new Oracle Access Manager 11g Access Tester enables IT professionals and administrators to simulate interactions between registered Oracle Access Manager Agents and Servers. This is useful when testing security policy definitions or troubleshooting issues involving agent connections.

Transition from Test to Production: Oracle Access Manager 11g enables moving configuration or policy data from one Oracle Access Manager 11g deployment to another (from a small test deployment to a production deployment, for example). Support for the creation of new topologies is based on templates. You can also copy and move policy changes.

Co-existence and Upgrades for OSSO 10g: The Oracle-provided Upgrade Assistant scans the existing OracleAS 10g SSO server configuration, accepts as input the 10g OSSO policy properties file and schema information, and transfers configured partner applications into the destination Oracle Access Manager 11g SSO.


See Also:


16.1.1 Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate

This topic is required for only 10g custom AccessGates. Skip this topic if it does not apply to your environment.

The Application Authenticator application domain is delivered with OAM 11g. It is pre-seeded with the policy objects that enables integration with applications deployed in WebLogic environments using the OAM Authentication Provider as the security provider. It is not associated with WebGate provisioning. When you provision a WebGate or AccessGate to use this (or another existing application domain), you will decline having policies created automatically.

The Application Authenticator application domain comes into play with the custom 10g AccessGate used with the OAM Authenticator (and the Identity Asserter for Oracle Web Services Manager). In this case, the custom AccessGate (not WebGate) contacts the WebLogic Server directly with a token to authenticate the user before OAM 11g is contacted.

The Application Authenticator application domain protects only resources of type wl_authen and is seeded with two authentication policies and one authorization policy. The following wl_authen resources are also seeded in this domain:

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion protected by LDAPNoPasswordValidationScheme


Note:

Only resources of type wl_authen are allowed in this domain; no other resource types can be added. Policies and Responses for wl_authen resources can be added. However, ideally, you will not need to modify this domain.

Figure 16-1 illustrates details of the seeded Application Authenticator application domain in the OAM 11g Administration Console. The page shown describes the pre-seeded User ID Assertion authentication policy, which protects the /Authen/UsernameAssertion resource. The authentication scheme for this policy is also shown along with the resources that are protected by the policy.

Figure 16-2 illustrates pre-seeded Responses for the User ID Assertion authentication policy. For more information about Responses, see the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Figure 16-3 illustrates the pre-seeded Application SSO authentication policy, the resources protected by this policy, and the authentication scheme.

Figure 16-4 illustrates Pre-seeded Responses for the Application SSO authentication policy in the application domain.

Figure 16-5 illustrates the pre-seeded Application SSO authorization policy and Resources in the application domain.

Authorization Constraints: There are no pre-seeded Application SSO authorization policy Constraints in this application domain. However, you can add constraints as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Authorization Responses: There are no pre-seeded Application SSO authorization policy Responses in the application domain. However, you can add responses as described in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

16.2 Deploying the Oracle Access Manager 11g SSO Solution

This section introduces how to implement OAM 11g with the Authentication Provider when you have applications that are (or will be) deployed in a WebLogic container.

This section provides the following topics to help you implement OAM 11g SSO when you have applications deployed in a WebLogic container. Aside from these uniquely OAM 11g methods, implementing OAM solutions are the same whether you have OAM 11g or OAM 10g:


See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for details about the scenario for Identity Propagation with the OAM Token.

16.2.1 Installing the Authentication Provider with Oracle Access Manager 11g

The following overview outlines the tasks that must be completed to install the required components and files for the Oracle Access Manager 11g SSO solution using the Authentication Provider. While many of these tasks are nearly the same for Oracle Access Manager 11g and Oracle Access Manager 10g, there are a few differences.


See Also:

Oracle Fusion Middleware Installation Guide for Oracle Identity Management for installation and initial configuration details for Oracle Access Manager 11g.

Task overview: Installing components for use with the Authentication Provider and OAM 11g

  1. Install and set up Oracle Internet Directory for Oracle Access Manager.

  2. Install and set up Oracle WebLogic Server 10.3.1+.

  3. Optional: Install a Fusion Middleware product (Oracle Identity Manager, Oracle SOA Suite, or Oracle Web Center for example):


    Note:

    Without a Fusion Middleware application, you must acquire the required JAR and WAR files as described in later procedures.

  4. Install OHS 11g for the Oracle Access Manager WebGate, if needed:

    • Identity Asserter: Requires Oracle HTTP Server 11g Web server configured as a reverse proxy in front of Oracle WebLogic Server.

      WebGate: For identity assertion with the OAM Identity Asserter, a perimeter Webgate is required (installed and configured) on the OHS Web Server.

    • Authenticator or Oracle Web Services Manager: No Web server is required for the custom AccessGate. The protected resource is accessed using its URL on the Oracle WebLogic Server.

  5. Authentication Provider Files: Confirm the required JAR and WAR files as follows:

    1. Confirm the location of required JAR files in the following Fusion Middleware path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar
      
    2. Locate the console-extension WAR file in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov 
      ider.war
      
    3. Copy the WAR file to the following path in the WebLogic Server home:

      WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
      
  6. Oracle Access Manager 11g:

    1. Install Oracle Access Manager and perform initial configuration as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.

    2. Trusted Header Assertion: Go to My Oracle Support, retrieve Bundle Patch 02 (Oracle Access Manager Bundle Patch 11.1.1.5.2), and apply it as described in the companion readme file: http://support.oracle.com.

  7. AccessGate for the Authenticator (or for Oracle Web Services Manager):

16.2.2 Converting Oracle Access Manager Certificates to Java Keystore Format

Oracle recommends that all Java components and applications use JKS as the keystore format. This topic provides steps to convert Oracle Access Manager X.509 certificates to Java Keystore (JKS) format. These steps, when followed properly, generate the JKS stores that can be used while the Java NAP client wants to communicate with an OAM Server in Simple or Cert (certificate) mode.


Note:

This procedure is required regardless of the SSO mechanism you choose.

When communicating in Simple or Cert mode, the OAM Server uses a key, server certificate, and CA chain files:

  • aaa_key.pem: the random key information generated by the certificate-generating utilities while it sends a request to a Root CA. This is your private key. The certificate request for WebGate generates the certificate-request file aaa_req.pem. You must send this WebGate certificate request to a root CA that is trusted by the OAM Server. The root CA returns the WebGate certificates, which can then be installed either during or after WebGate installation.

  • aaa_cert.pem: the actual certificate for the OAM Server, signed by the Root CA.

  • aaa_chain.pem: the public certificate of the Root CA. This is used when peers communicating in Simple or Cert mode perform an SSL handshake and exchange their certificates for validity. In Simple Mode, the aaa_chain.pem is the OpenSSL certificate located inOAMServer_install_dir/access/oblix/tools/openssl/simpleCA/cacert.pem

Here, aaa is the name you specify for the file (applicable only to Cert and chain files).

You can edit an existing certificate with a text editing utility to remove all data except that which is contained within the CERTIFICATE blocks. You then convert the edited certificate to JKS format, and import it into the keystore. Java KeyTool does not allow you to import an existing Private Key for which you already have a certificate. You must convert the PEM format files to DER format files using the OpenSSL utility.

To convert an Oracle Access Manager certificate to JKS format and import it

  1. Install and configure Java 1.6 or the latest version.

  2. Copy the following files before editing to retain the originals:

    • aaa_chain.pem

    • aaa_cert.pem

    • cacert.pem, only if configuring for Simple mode

  3. Edit aaa_chain.pem using TextPad to remove all data except that which is contained within the CERTIFICATE blocks, and save the file in a new location to retain the original.

    -----BEGIN CERTIFICATE-----
    ...
    CERTIFICATE
    ...
    -----END CERTIFICATE-----
    
  4. Run the following command for the edited aaa_chain.pem:

    JDK_HOME\bin\keytool" -import -alias root_ca -file aaa_chain.pem -keystore 
    rootcerts
    

    Here you are assigning an alias (short name) root_ca to the key. The input file aaa_chain.pem is the one that you manually edited in step 3. The keystore name is rootcerts.

    You must give a password to access the keys stored in the newly created keystore.


    Note:

    To ensure security, Oracle recommends that you allow the keytool to prompt you to enter the password. This prompt occurs automatically when the "-storepass" flag is omitted from the command line.

  5. Enter the keystore password, when asked. For example:

    Enter keystore password: <keystore_password>
    Re-enter new keystore password: <keystore_password>
    
  6. Enter Yes when asked if you trust this tool:

    Trust this certificate? [no]: yes
    
  7. Confirm that the certificate has been imported to the JKS format by executing the following command and then the password.

    JDK_HOME\bin\keytool" -list -v -keystore "rootcerts"
    Enter keystore password: <keystore_password>
    
  8. Look for a response like the following:

    Keystore type: JKS
    Keystore provider: SUN
    Your keystore contains n entries
    Alias name: root_ca
    Creation date: April 19, 2009
    Entry type: trustedCertEntry
    
    Owner: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, 
    O="Oblix, Inc.", L=Cupertino, ST= California , C=US
    
    Issuer: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, 
    O="Oblix, Inc.", L=Cupertino, ST= California ,C=US
    
    Serial number: x
    Valid from: Tue Jul 25 23:33:57 GMT+05:30 2000 until: Sun Jul 25 23:33:57
    GMT+05:30 2010
    
    Certificate fingerprints
      MD5:  CE:45:3A:66:53:0F:FD:D6:93:AD:A7:01:F3:C6:3E:BC
      SHA1: D6:86:9E:83:CF:E7:24:C6:6C:E1:1A:20:28:63:FE:FE:43:7F:68:95
      Signature algorithm name: MD5withRSA
      Version: 1
    *******************************************
    
  9. Repeat steps 3 through 7 for the other PEM files (except aaa_chain.pem unless there is a chain).

  10. Convert the aaa_key.pem file to DER format using the OpenSSL utility in the OAM Server installation directory path. For example:

    OAM_Server_HOME\access\oblix\tools\openssl>openssl pkcs8 -topk8  
    -nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der –outform DER 
    

    Here the input file is aaa_key.pem and the output file is aaa_key.der. Additional options include:

  11. Simple or Cert Mode: In the PEM file (in this case, aaa_cert.pem), enter the pass phrase for the OAM Server if it is configured for Simple or Cert mode.

    Passphrase for the certificate
    
  12. Run the following command to convert the aaa_cert.pem file to DER format.

    AccessServer_install_dir\access\oblix\tools\openssl>openssl x509 -in  
    aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER
    
  13. Import the DER format files into a Java keystore using the ImportKey utility. For example:

    Java_install_dir\doc>java -Dkeystore=jkscerts ImportKey aaa_key.der   
    aaa_cert.der
    
  14. Review the results in the window, which should look something like the following example:

    Using keystore-file : jkscerts
    One certificate, no chain
    Key and certificate stored
    Alias:importkey  Password:your_password 
    

16.2.3 Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header assertion or clear text header mechanism, skip this topic.

Provisioning is the process of registering an agent and creating an application domain to use OAM 11g authentication and authorization services.You must provision a WebGate with OAM 11g whether you are preparing to install a fresh 11g or 10g instance or you have a legacy 10g WebGate installed.

The term WebGate is used for WebGates (and for the custom 10g AccessGates used with the Authenticator and the Identity Asserter for Oracle Web Services Manager). Unless explicitly stated, topics apply equally to both.

When you have multiple agents, each one can be provisioned independently or you can use a single OAM Agent registration for multiple agents.


Note:

The Application Authenticator application domain is pre-seeded and delivered with OAM 11g. When you provision an OAM Agent to use this (or another existing) application domain, decline the option of having policies automatically created.

The following topics are provided:

16.2.3.1 About WebGate Provisioning Methods for Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header or clear text header mechanism, skip this topic.

Table 16-2 outlines the methods and tools you can use to provision WebGates for use with OAM 11g. The remote registration tool enables you to specify a small amount or all WebGate parameters using templates.

During remote registration, you must provide the details discussed in Table 16-3.


See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service for a complete list of WebGate parameters

16.2.3.2 Provisioning a WebGate with Oracle Access Manager 11g

This task is required for only the session token mechanism (ObSSOCookie). If you are implementing either a trusted header or clear text header mechanism, skip this topic.

Provisioning a WebGate or AccessGate involves the same steps. You can provision a new instance for use with the Authentication Provider or you can refer to an existing registration when configuring the provider.

In this example, an OAM 10g WebGate is provisioned using the OAMRequest_short.xml template. The registered agent is named my-wl-agent1, protecting /.../*, and declaring a public resource, /public/index.html. Your values will be different.


Note:

When provisioning an OAM 11g WebGate, use the OAM11gRequest_short.xml template.


See Also:

Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service

To provision a WebGate with OAM 11g

  1. Acquire the Tool: On the computer to host the WebGate, acquire the remote registration tool and set up the script for your environment. For example:

    1. Locate RREG.tar.gz file in the following path:

      WLS_home/Middleware/domain_home/oam/server/rreg/client/RREG.tar.gz 
      
    2. Untar RREG.tar.gz file to any suitable location. For example: rreg/bin/oamreg.

    3. In the oamreg script, set the following environment variables based on your situation (client side or server side) and information in Table 6–7 in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service:


      OAM_REG_HOME = exploded_dir_for_RREG.tar/rreg
      JDK_HOME = Java_location_on_the_computer
  2. Create the registration request:

    1. Locate the *Request_short.xml file and copy it to a new location and name. For example:

      WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/
      

      Copy: OAMRequest_short.xml (or OAM 11gRequest.xml)

      To: my-wl-agent1.xml

    2. Edit my-wl-agent1.xml to include details for your environment, and set automatic policy creation to false. For example:

      <OAMRegRequest>
          <serverAddress>http://sample.us.oracle.com:7001</serverAddress>
          <hostIdentifier>my-wl</hostIdentifier>
          <agentName>my-wl-agent1</agentName>
          <primaryCookieDomain>.us.example.com</primaryCookieDomain>
          <autoCreatePolicy>false</autoCreatePolicy>
          <logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
      </OAMRegRequest>
      

      See Also:

      "Creating the Registration Request" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service

  3. Provision the agent. For example:

    1. Locate the remote registration script.


      Linux: rreg/bin/oamreg.sh
      Ensure the script has executable permission: chmod +x oamreg.sh

      Windows: rreg\bin\oamreg.bat

    2. From the directory containing the script, execute the script using inband mode. For example:

      $ ./bin/oamreg.sh inband input/my-wl-agent1.xml

      Welcome to OAM Remote Registration Tool!
      Parameters passed to the registration tool are:
      Mode: inband
      Filename: ...
      
    3. When prompted, enter the following information using values for your environment:

      Enter your agent username: userame
         Username:  userame
      Enter agent password: ********
      Do you want to enter a Webgate password?(y/n)
          n
      iv.Do you want to import an URIs file?(y/n)
          n
      
    4. Review the final message to confirm that this was a successful registration:

      Inband registration process completed successfully! Output artifacts are 
      created in the output folder"
      
  4. Confirm in the Console: Log in to the Oracle Access Manager Console and review the new registration:

    1. From the OAM 11g Console System Configuration tab, Access Manager Settings section, expand the SSO Agents nodes to search for the agent you just provisioned:


      Access Manager Settings
      SSO Agents
      OAM Agents
      Search
    2. In the Search Results table, click the agent's name to display the registration page and review the details, which you will use later. For example:

      Agent Name—During WebGate installation, enter this as the WebGate ID. If you deploy the custom 10g AccessGate, enter this as the AccessGate Name when configuring the OAM Authentication Provider in the WebLogic Administration Console.

      Access Client Password—During WebGate installation, enter this as the WebGate password. If no password was entered, you can leave the field blank.

      Access Server Host Name—Enter the DNS host name for the primary OAM 11g Server with which this WebGate is registered.

    3. OAM Proxy Port—From the Oracle Access Manager Console, System Configuration tab, Common Configuration section, open Server Instances and locate the port on which the OAM Proxy is running.

  5. Ignore the Obaccessclient.xml file, which is created during provisioning, for now.

  6. Proceed as needed for your environment:

16.2.4 Configuring Identity Assertion for SSO with Oracle Access Manager 11g

This section describes the unique steps needed to configure Oracle Access Manager 11g Identity Assertion for Single Sign-On with your application.

Task overview: Deploying the Identity Asserter for SSO with OAM 11g includes

  1. Finishing all prerequisite tasks for the mechanism you are implementing:

  2. Establishing Trust with Oracle WebLogic Server

  3. Configuring Providers in the WebLogic Domain

  4. Trusted Header Assertion: Configuring Digital Signature Verification

  5. Trusted Header Assertion: Configuring Policies

  6. Configuring Centralized Log Out for Oracle Access Manager 11g

  7. Synchronizing the User and SSO Sessions: SSO Synchronization Filter

  8. Testing Oracle Access Manager Identity Assertion for Single Sign-on

16.2.4.1 Establishing Trust with Oracle WebLogic Server

The following topics explain the tasks you must perform to set up the application for single sign-on with the Oracle Access Manager Identity Asserter.

Task overview: Establishing Trust with Oracle WebLogic Server

  1. Setting Up the Application Authentication Method for Identity Asserter for Single Sign-On

  2. Confirming mod_weblogic for Oracle Access Manager Identity Asserter

  3. Clear Text Header: Establishing Trust between Oracle WebLogic Server and Other Entities

16.2.4.1.3 Clear Text Header: Establishing Trust between Oracle WebLogic Server and Other Entities

The Oracle WebLogic Connection Filtering mechanism must be configured for creating access control lists and for accepting requests from only the hosts where Oracle HTTP Server and the front-end Web server are running.


Note:

This filter is required for security when you use Identity Assertion with the Clear Text Header mechanism. This task is optional when you use one of the other mechanisms.

A network connection filter is a component that controls the access to network level resources. It can be used to protect resources of individual servers, server clusters, or an entire internal network. For example, a filter can deny non-SSL connections originating outside of a corporate network. A network connection filter functions like a firewall since it can be configured to filter protocols, IP addresses, or DNS node names. It is typically used to establish trust between Oracle WebLogic Server and foreign entities.

To configure a connection filter to allow requests from only mod_weblogic and the host where OHS 11g is running, perform the procedure here.


Note:

This chapter uses the generic name of the WebLogic Server plug-in for Apache: mod_weblogic. For Oracle HTTP Server 11g, the name of this plug-in is mod_wl_ohs; the actual binary name is mod_wl_ohs.so. Examples show exact syntax for implementation.

WebLogic Server provides a default connection filter: weblogic.security.net.ConnectionFilterImpl. This filter accepts all incoming connections and also provides static factory methods that allow the server to obtain the current connection filter. To configure this connection filter to deny access, simply enter the connection filters rules in the WebLogic Server Administration Console.

You can also use a custom connection filter by implementing the classes in the weblogic.security.net package. Like the default connection filter, custom connection filters are configured in the WebLogic Server Administration Console.

Connection Filter Rules: The format of filter rules differ depending on whether you are using a filter file to enter the filter rules or you enter the filter rules in the Administration Console. When entering the filter rules on the Administration Console, enter them in the following format:

targetAddress localAddress localPort action protocols

Table 16-4 provides a description of each parameter in a connection filter.

The Connection Logger Enabled attribute logs successful connections and connection data in the server. This information can be used to debug problems relating to server connections.


See Also:

"Configuring Security in a WebLogic Domain" in Oracle Fusion Middleware Securing Oracle WebLogic Server

To configure a connection filter to allow requests from Oracle HTTP Server host

  1. Log in to the Oracle WebLogic Administration Console.

  2. Click Domain under Domain Configurations.

  3. Click the Security tab, click the Filter tab.

  4. Click the Connection Logger Enabled attribute to enable the logging of accepted messages for use when debugging problems relating to server connections.

  5. Specify the connection filter to be used in the domain:

    • Default Connection Filter: In the Connection Filter attribute field, specify weblogic.security.net.ConnectionFilterImpl.

    • Custom Connection Filter: In the Connection Filter attribute field, specify the class that implements the network connection filter, which should also be specified in the CLASSPATH for Oracle WebLogic Server.

  6. Enter the appropriate syntax for the connection filter rules.

  7. Click Save.

  8. Restart the Oracle WebLogic Server.

  9. Proceed to "Configuring Providers in the WebLogic Domain".

16.2.4.2 Configuring Providers in the WebLogic Domain

The information here applies equally to OAM 11g and OAM 10g. This topic is divided as follows:

16.2.4.2.1 About Oracle WebLogic Server Authentication and Identity Assertion Providers

This topic introduces only a few types of Authentication Providers for a WebLogic security realm, if you are new to them.

Each WebLogic security realm must have one at least one Authentication Provider configured. The WebLogic Security Framework is designed to support multiple Authentication Providers (and thus multiple LoginModules) for multipart authentication. As a result, you can use multiple Authentication Providers as well as multiple types of Authentication Providers in a security realm. The Control Flag attribute determines how the LoginModule for each Authentication Provider is used in the authentication process.

Oracle WebLogic Server offers several types of Authentication and Identity Assertion providers including, among others:

  • The default WebLogic Authentication Provider (Default Authenticator) allows you to manage users and groups in one place, the embedded WebLogic Server LDAP server. This Authenticator is used by the Oracle WebLogic Server to login administrative users.

  • Identity Assertion uses token-based authentication; the Oracle Access Manager Identity Asserter is one example. This must be configured to use the appropriate action for the installed WebGate (either 10g or 11g).

  • LDAP Authentication Providers store user and group information in an external LDAP server. They differ primarily in how they are configured by default to match typical directory schemas for their corresponding LDAP server.

    Oracle WebLogic Server 10.3.1+ provides OracleInternetDirectoryAuthenticator.

When you configure multiple Authentication Providers, use the JAAS Control Flag for each provider to control how the Authentication Providers are used in the login sequence. You can choose the following the JAAS Control Flag settings, among others:

  • REQUIRED—The Authentication Provider is always called, and the user must always pass its authentication test. Regardless of whether authentication succeeds or fails, authentication still continues down the list of providers.

  • SUFFICIENT—The user is not required to pass the authentication test of the Authentication Provider. If authentication succeeds, no subsequent Authentication Providers are executed. If authentication fails, authentication continues down the list of providers.

  • OPTIONAL—The user is allowed to pass or fail the authentication test of this Authentication Provider. However, if all Authentication Providers configured in a security realm have the JAAS Control Flag set to OPTIONAL, the user must pass the authentication test of one of the configured providers.

When additional Authentication Providers are added to an existing security realm, the Control Flag is set to OPTIONAL by default. You might need to change the setting of the Control Flag and the order of providers so that each Authentication Provider works properly in the authentication sequence.


See Also:

"Configuring Authentication Providers" in Oracle Fusion Middleware Securing Oracle WebLogic Server for a complete list of Authentication Providers and details about configuring the Oracle Internet Directory provider to match the LDAP schema for user and group attributes

16.2.4.2.2 About the Oracle WebLogic Scripting Tool (WLST)

This topic introduces WLST, if you are new to it.

You can add providers to a WebLogic domain using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.

WLST is a Jython-based command-line scripting environment that you can use to manage and monitor WebLogic Server domains. Generally, you can use this tool online or offline. You can use this tool interactively on the command line in batches supplied in a file (Script Mode, where scripts invoke a sequence of WLST commands without requiring your input), or embedded in Java code.

When adding Authentication Providers to a WebLogic domain, you can use WLST online to interact with an Authentication Provider and add, remove, or modify users, groups, and roles.

When you use WLST offline to create a domain template, WLST packages the Authentication Provider's data store along with the rest of the domain documents. If you create a domain from the domain template, the new domain has an exact copy of the Authentication Provider's data store from the domain template. However, you cannot use WLST offline to modify the data in an Authentication Provider's data store.


Note:

You cannot use WLST offline to modify the data in an Authentication Provider's data store.

16.2.4.2.3 Configuring Oracle WebLogic Server for a Web Application Using ADF Security, OAM SSO, and OPSS SSO

On the Oracle WebLogic Server, you can run a Web application that uses Oracles Application Development Framework (Oracle ADF) security, integrates with Oracle Access Manager Single Sign On (SSO), and uses Oracle Platform Security Services (OPSS) SSO for user authentication. However before the Web application can be run, you must configure the domain-level jps-config.xml file on the application's target Oracle WebLogic Server for the Oracle Access Manager security provider.

The domain-level jps-config.xml file is in the following path and should not be confused with the deployed application's jps-config.xml file:

domain_home/config/fmwconfig/jps-config.xml 

You can use an Oracle Access Manager-specific WLST script to configure the domain-level jps-config.xml file, either before or after the Web application is deployed. This Oracle JRF WLST script is named as follows:

Linux: wlst.sh

Windows: wlst.cmd

The Oracle JRF WLST script is available in the following path if you are running through JDev:

     $JDEV_HOME/oracle_common/common/bin/

In a standalone JRF WebLogic installation, the path is:

     $Middleware_home/oracle_common/wlst

Note:

The Oracle JRF WLST script is required. When running WLST for Oracle Java Required Files (JRF), do not use the WLST script under $JDEV_HOME/wlserver_10.3/common/bin.

Command Syntax

addOAMSSOProvider(loginuri, logouturi, autologinuri)

Table 16-5 defines the expected value for each argument in the addOAMSSOProvider command line.

Prerequisites

Configuring Providers in the WebLogic Domain

To modify domain-level jps-config.xml for a Fusion Web application with Oracle ADF Security enabled

  1. On the computer hosting the Oracle WebLogic Server and the Web application using Oracle ADF security, locate the Oracle JRF WLST script. For example:

    cd $ORACLE_HOME/oracle_common/common/bin
    
  2. Connect to the computer hosting the Oracle WebLogic Server:

    connect login_id password hostname:port
    

    For example, the Oracle WebLogic Administration Server host could be localhost using port 7001. However, your environment might be different.

  3. Enter the following command-line arguments with values for the application with ADF security enabled:

    addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication", 
    logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
    
  4. Stop and start the Oracle WebLogic Server.

  5. Perform the following tasks as described in:

16.2.4.2.4 Setting Up Providers for Oracle Access Manager 11g Identity Assertion

This topic describes how to configure providers in the WebLogic security domain to perform single sign-on with the Oracle Access Manager Identity Asserter. Several Authentication Provider types must be configured and ordered:

The following procedure uses the WebLogic Administration Console.


Note:

With an Oracle Fusion Middleware application installed, you have the required provider JAR file. Skip Step 1.

To set up Providers for Oracle Access Manager single sign-on in a WebLogic domain

  1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider:

    1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      
    2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0):

      oamAuthnProvider<version number>.zip  
      
    3. Extract and copy oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
      
  2. With Oracle Fusion Middleware Application Installed:

    1. Locate oamauthenticationprovider.war in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
      der.war
      
    2. Copy oamauthenticationprovider.war to the following location:

      BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
      provider.war  
      
  3. Log in to the WebLogic Administration Console.

  4. Click Security Realms, Default Realm Name, and click Providers.

  5. OAM Identity Asserter: Perform the following steps to add this provider:

    1. Click New, and then enter a name and select a type:

      Name: OAM Identity Asserter

      Type: OAMIdentityAsserter

      OK

    2. In the Authentication Providers table, click the newly added authenticator.

    3. Click the Common tab, set the Control Flag to REQUIRED.

    4. On the Common tab, specify one Chosen Active Type for your SSO mechanism (Table 15-1). For example:


      OAM_IDENTITY_ASSERTION
    5. Save the configuration.

  6. OID Authenticator: Perform the following steps to add this provider.

    1. Click Security Realms, Default Realm Name, and click Providers.

    2. Click New, enter a name, and select a type:

      Name: OID Authenticator

      Type: OracleInternetDirectoryAuthenticator

      OK

    3. In the Authentication Providers table, click the newly added authenticator.

    4. On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, and then click Save.

    5. Click the Provider Specific tab and specify the following required settings using values for your own environment:

      Host: Your LDAP host. For example: localhost

      Port: Your LDAP host listening port. For example: 6050

      Principal: LDAP administrative user. For example: cn=orcladmin

      Credential: LDAP administrative user password.

      User Base DN: Same searchbase as in Oracle Access Manager.

      All Users Filter: For example: (&(uid=*)(objectclass=person))

      User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid

      Group Base DN: The group searchbase (same as User Base DN)

      Do not set the All Groups filter as the default works fine as is.

      Save.

  7. Default Authenticator: Perform the following steps to set up the Default Authenticator for use with the Identity Asserter:

    1. Go to Security Realms, Default Realm Name, and click Providers.

    2. Click Authentication, Click DefaultAuthenticator to see its configuration page.

    3. Click the Common tab and set the Control Flag to SUFFICIENT.

    4. Save.

  8. Reorder Providers:

    1. Click Security Realms, Default Realm Name, Providers.

    2. On the Summary page where providers are listed, click the Reorder button

    3. On the Reorder Authentication Providers page, select a provider name and use the arrows beside the list to order the providers as follows:

      OAM Identity Asserter (REQUIRED)

      OID Authenticator (SUFFICIENT)

      Default Authenticator (SUFFICIENT)

    4. Click OK to save your changes

  9. Activate Changes: In the Change Center, click Activate Changes.

  10. Reboot Oracle WebLogic Server.

  11. Proceed as follows:

As mentioned earlier, a login form shipped with 10g WebGate is used only with OAM 10g Access Server. For OAM 11g, neither the 10g WebGate nor 11g WebGate provide a login page.


Note:

The OAM 11g Server displays a login page. No set up is needed.

16.2.4.3 Trusted Header Assertion: Configuring Digital Signature Verification

This is a manual task. The Oracle Access Manager certificate public key is required for digital signature verification. The certificate, which is consumed by the Identity Asserter, must be in the .oamkeystore.

For the SSO Sync Filter to consume the certificate, you need to provide the truststore to the filter. SSO Sync Filter behavior can be altered for application requirements by passing various over-riding system properties to WebLogic. To do this, you add a property in Oracle WebLogic startup script (setDomainEnv.sh) under EXTRA_JAVA_PROPERTIES. The truststore location can be provided as the system property. By default filter will look for keystore at ssofilter.jar location. If not found then it looks in system property.

The following procedure guides as you retrieve the .oamkeystore password required to perform export and import operations. After you export and import the required OAM certificate, you provision the keystore to enable the Identity Asserter to consume the certificate. Finally, you choose the OAM_IDENTITY_ASSERTION token type, provision the certificate in the SSO Sync Filter, and confirm that the authorization policy enables Identity Assertion.

To configure digital signature verification for trusted header assertion

  1. Retrieve the .oamkeystore password using WLST script tool as follows:

    1. Locate the WLST tool in your $MW_HOME/Oracle_IDM1/common/bin.

    2. Execute wst.sh: $ ./wlst.sh.

    3. Confirm execution with the following onscreen messages:

      Initializing WebLogic Scripting Tool (WLST) ...
      
      Jython scans all the jar files it can find at first startup. Depending on 
      the system, this process may take a few minutes to complete, and WLST may
      not return a prompt right away
      
      Welcome to WebLogic Server Administration Scripting Shell
      
      Type help() for help on available commands
      
    4. Execute wls:/offline> connect() and supply information for your environment (WebLogic Administrator username and password and AdminServer URL). For example:

      Please enter your username: weblogic  
      Please enter your password: password 
      Please enter your server URL //localhost:7001  
      not return a prompt right away
      
      Connecting to ... 
      Successfully connected to Admin Server 'AdminServer' ... domain 'base_domain'.
      
      Warning: An insecure protocol was used to connect to the server. 
      To ensure on-the-wire security, the SSL port or Admin port should be used 
      instead. 
      wls:/base_domain/serverConfig
      
    5. Execute wls:/base_domain/serverConfig> domainRuntime() and check the following onscreen messages. For example:

      Location changed to domainRuntime tree. This is a read-only tree with   
      DomainMBean as the root
      
      For more help, use help(domainRuntime) 
      
      wls:/base_domain/domainRuntime>  
      
    6. Execute wls:/base_domain/domainRuntime> listCred(map="OAM_STORE",key="jks"). For example:

      Already in Domain Runtime Tree  
      PASSWORD: lleoi4sbkpo3bj8fg55k7jgbgh 
      wls:/base_domain/domainRuntime>   
      
  2. Export the alias to a certificate file using the JDK6 keytool, as follows:

    jdk/bin]$ keytool -exportcert -alias "assertion-cert" -keystore .oamkeystore 
    -storepass gtml6es9qderjc66f76hvtqm5a -storetype JCEKS -file assertion.cer
    
  3. Import the certificate file using the JDK6 keytool, as follows:


    Note:

    The keystore alias oam.assertion.cert and the keystore name oamiap-keystore.jks are fixed. Use those names only.

    jdk/bin $ keytool -importcert -trustcacerts -alias "oam.assertion.cert" -file   
    assertion.cer -keystore /scratch/oamiap-keystore.jks -storepass password 
    -storetype JKS 
    
  4. Provision the Identity Asserter keystore for consumption of the OAM certificate with the public key in oamiap-keystore.jks:

    1. From the WebLogic Console, Security Realm, Identity Asserter entry, add the absolute path of oamiap-keystore.jks in the provider-specific configuration.

    2. Select token type OAM_IDENTITY_ASSERTION in provider-specific configuration.

    3. Save this configuration.

    OAM Keystore Asserter
  5. Provision .oamkeystore in the SSO Sync Filter, as follows:

    By default, the filter looks for the keystore in the ssofilter.jar location. If not found there, the system property is checked.

    1. Default configuration: Place the keystore file oamiap-keystore.jks in the same location as ssofilter.jar. For example: $MW_HOME/oracle_common/modules/oracle.ssofilter_11.1.1

    2. Fallback Mechanism: Set the keystore file oamiap-keystore.jks as a systemproperty in setDomainEnv.sh ($MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh):

      -Dsso.filter.oam.keystore=/scratch/keystore/oamiap-keystore.jks
      
  6. Set System Properties for OAM_IDENTITY_ASSERTION, as follows:

    1. Stop the WebLogic Server.

    2. Open the file setDomainEnv.sh in $MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh

      
    3. Add the following property under EXTRA_JAVA_PROPERTIES, and save the file:

        -Dsso.filter.ssotoken=OAM_IDENTITY_ASSERTION
    
  7. Start the WebLogic Server.

  8. Proceed to "Trusted Header Assertion: Configuring Policies".

16.2.5 Configuring the Authenticator Function for Oracle Access Manager 11g

With the Authenticator function, the user is challenged for credentials based on the authentication method that is configured within the application web.xml. However, an Oracle Access Manager authentication scheme is required and available in the pre-seeded application domain that is delivered with Oracle Access Manager 11g. It protects the following resources (resource type wl_authen):

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion

You can add Responses and Constraints to policies. However, no other configuration is needed.

For more information about the pre-seeded application domain, see "Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate".

Prerequisites

Tasks to configure the Oracle Access Manager Authenticator are described in the following overview.

Task overview: Configuring the Authenticator function for OAM includes

  1. Ensuring that all prerequisite tasks have been performed

  2. Configuring Providers for the Authenticator in a WebLogic Domain

  3. Configuring the Application Authentication Method for the Authenticator

  4. Mapping the Authenticated User to a Group in LDAP

  5. Configuring Centralized Log Out for Oracle Access Manager 11g

  6. Testing the Oracle Access Manager Authenticator Implementation

16.2.5.1 Configuring Providers for the Authenticator in a WebLogic Domain

This topic includes a procedure that you can use to add and configure the appropriate Authentication providers in a WebLogic domain.

The Oracle Access Manager Authenticator must be configured along with the Default Authentication Provider in a WebLogic domain.

The following procedure describes this task using the WebLogic Administration Console. You can also add these using the Oracle WebLogic Scripting Tool (WLST).


Note:

When an Oracle Fusion Middleware application is installed, you have the required files and can skip Step 1.

To configure providers for the Oracle Access Manager Authenticator in a WebLogic domain

  1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.

    1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      
    2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:

      oamAuthnProvider<version>.zip 
      
    3. Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
       
      
  2. Go to the Oracle WebLogic Administration Console.

  3. With Oracle Fusion Middleware Application Installed:

    1. Locate oamauthenticationprovider.war in the following path:

      ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
      der.war 
      
    2. Copy oamauthenticationprovider.war to the following location:

      BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
      provider.war  
      
  4. Go to the Oracle WebLogic Administration Console.

  5. Click Lock & Edit, if desired.

  6. OAM Authenticator:

    1. Click Security Realms and select the realm you want to configure.

    2. Select Providers, Authentication, and click New to display the Create a New Authentication Provider page

    3. Enter a name and select a type:

      Name OAMAuthN

      Type: OAMAuthenticator

      OK

    4. Click the name of the Authentication provider you have just created to display the Provider Configuration page.

    5. In the Provider Configuration page, set the required values as follows:

      Access Gate Name: The name of the AccessGate used by the Provider. This must match exactly the name of an OAM Agent registration in the Oracle Access Manager Console.


      Note:

      You can have one or more 10g OAM Agents registered with OAM 11g. Be sure to choose the correct Agent registration name.

      Access Gate Password: The same password, if any, that is as defined for the Agent registration (see the Oracle Access Manager Console).

      Primary Access Server: The host:port of the primary OAM Server that is associated with this AccessGate in the Oracle Access Manager Console.

      Advanced Configuration: Following are several advanced configuration values.

      Transport Security: The communication mode between OAM Server and AccessGate: open, simple, or cert.

      If transport security is Simple or Cert, include the following parameters and values:

      Trust Store: The absolute path of JKS trust store used for SSL communication between the provider and the OAM Server.

      Key Store: The absolute path of JKS key store used for SSL communication between the provider and the OAM Server.

      Key Store Pass Phrase: The password to access the key store.

      Simple mode pass phrase: The password shared by AccessGate and OAM Server for simple communication modes.

      Secondary OAM Server: The host:port of the secondary OAM Server that is associated with this AccessGate in the Oracle Access Manager Console.

      Maximum OAM Server Connections in Pool: The maximum number of connections that the AccessGate opens to the OAM Server. The default value is 10.


      Note:

      The Maximum OAM Server Connections in Pool (or Minimum OAM Server Connections in Pool) settings in the WebLogic Administration Console are different from the Maximum (or Minimum) Connections specified in the Oracle Access Manager Console.

      Minimum Access Server Connections in Pool: The minimum number of connections that the Authentication provider uses to send authentication requests to the OAM Server. The default value is 5.


      See Also:

      "Oracle Access Manager Authentication Provider Parameter List" for descriptions and values of the common and provider-specific parameters

    6. Ensure that the parameter Control Flag is set to OPTIONAL initially.


      Note:

      Do not set the parameter Control Flag to REQUIRED until you have verified that the Authentication Provided is operational and configured correctly.

  7. In the Change Center, click Activate Changes.

  8. DefaultAuthenticator: Under the Providers tab, select DefaultAuthenticator, which changes its control flag to SUFFICIENT.

  9. Reorder: Under the Providers tab, reorder the providers so that DefaultAuthenticator is first (OAMAuthenticator follows DefaultAuthenticator).


    Note:

    If the Oracle Access Manager Authenticator flag is set to REQUIRED, or if Oracle Access Manager Authenticator is the only Authentication provider, perform the next step to ensure that the LDAP user who boots Oracle WebLogic Server is included in the administrator group that can perform this task. By default the Oracle WebLogic Server Admin Role includes the Administrators group.

  10. Oracle Access Manager Authenticator REQUIRED or the Only Authenticator: Perform the following steps to set user rights for booting Oracle WebLogic Server.

    1. Create an Administrators group in the directory server, if one does not already exist (or any other group for which you want boot access).


      Note:

      To provide access to any other group, you must create that group in the directory server and add the user who boots WebLogic Server in that group.

    2. Confirm that the LDAP user who boots Oracle WebLogic Server is included in the Administrators (or other) group.

    3. From the WebLogic Administration Console, go to Security Realms, myrealm, Roles and Policies, Global Roles.

    4. Select View Conditions for the Admin Role.

    5. Add the group and click Save.

  11. Reboot the WebLogic Server.

  12. Once the server has started, reset the Authentication Provider parameter Control Flag to the appropriate value (REQUIRED, OPTIONAL, or SUFFICIENT).


    Note:

    The recommended value is REQUIRED. To prevent a known issue, see "JAAS Control Flag".

  13. Proceed with "Configuring the Application Authentication Method for the Authenticator".

16.2.5.2 Configuring the Application Authentication Method for the Authenticator

This topic describes how to create the application authentication method for Oracle Access Manager Authenticator.

When you use the Oracle Access Manager Authenticator, all web.xml files in the application EAR file must specify BASIC in the element auth-method for the appropriate realm.

The auth-method can use BASIC or FORM values. While these look like similar values in Oracle Access Manager, the auth-method specified in web.xml files are used by Oracle WebLogic Server (not Oracle Access Manager).


Note:

For the Oracle Access Manager Authenticator, Oracle recommends auth-method BASIC in login-config within web.xml.

To configure the application authentication method for the Authenticator

  1. Locate the web.xml file in the application EAR file:

    WEB-INF/web.xml 
    
  2. Locate the auth-method in login-config and enter BASIC. For example:

    <security-constraint>
    <web-resource-collection>
    <web-resource-name>protected</web-resource-name>
    <url-pattern>/servlet</url-pattern>
    </web-resource-collection>
    <auth-constraint>
    <role-name>auth-users</role-name>
    </auth-constraint>
    </security-constraint>
    <login-config>
    <auth-method>BASIC</auth-method>
    </login-config>
    <security-role>
    <description>Authenticated Users</description>
    <role-name>auth-users</role-name>
    </security-role>
    
  3. Save the file.

  4. Redeploy and restart the application.

  5. Repeat for each web.xml file in the application EAR file.

  6. Proceed with "Mapping the Authenticated User to a Group in LDAP".

16.2.6 Configuring Identity Assertion for Oracle Web Services Manager and OAM 11g

This section describes how to set up the Oracle Access Manager Identity Asserter to enable validation of the token when you have Oracle Web Services Manager protecting Web services.

As discussed earlier, the Oracle Access Manager Identity Asserter works in two modes. The default mode of operation simply asserts the header that is set by WebGate at the perimeter, which handles most SSO situations. The alternate mode uses the custom AccessGate in oamAuthnProvider.jar. In this case, and with the absence of the header, the Identity Asserter contacts the OAM Server to validate the token. For more information about the token, see "Installing the Authentication Provider with Oracle Access Manager 11g".


Note:

The 10g custom AccessGate provided with the Authentication Provider is required for Identity Assertion for Oracle Web Services Manager.

With OAM 10g, you would need to manually create the policy domain and policies for this configuration. However, with OAM 11g, a pre-seeded application domain is delivered with policies that protect the following resources (resource type wl_authen):

  • /Authen/Basic

  • /Authen/SSOToken

  • /Authen/UsernameAssertion

You can add policies, Responses, or Constraints for resources of type wl_authen only. Ideally, however, you can use this application domain with no further configuration. For more information, see "Previewing Pre-Seeded OAM 11g Policies for Use by the 10g AccessGate".

When the Oracle Access Manager Identity Asserter is configured for both header and token validation modes, preference is given to the presence of the header. If the header is not present, the Identity Asserter contacts the OAM Server to validate the token. For more information on the token, see "Oracle Access Manager Authentication Provider Parameter List".

Prerequisites

Installing the Authentication Provider with Oracle Access Manager 11g

Session Token: Provisioning an OAM Agent with Oracle Access Manager 11g

Task overview: Deploying the Identity Asserter with Oracle Web Services Manager includes

  1. Configuring Providers in a WebLogic Domain for Oracle Web Services Manager

  2. Configuring Centralized Log Out for Oracle Access Manager 11g

  3. Testing the Identity Asserter with Oracle Web Services Manager

16.2.6.1 Configuring Providers in a WebLogic Domain for Oracle Web Services Manager

To use Oracle Access Manager Identity Asserter with Oracle Web Services Manager protected Web services, several Authentication providers must be configured and ordered in a WebLogic domain:

This procedure is nearly identical to the one for the Oracle Access Manager Identity Asserter with OAM 11g. The difference in this case is that Oracle Web Services Manager requires the custom 10g AccessGate and additional provider-specific values:

  • Primary Access Server: Specify the primary OAM Server host and port. For example: mnop:8888

  • Access Gate Name: The name of the AccessGate registration protecting the application. For example: AG1

  • Access Gate Password: The AccessGate password as specified in the Oracle Access Manager Console.

You can add these using either the Oracle WebLogic Administration Console or Oracle WebLogic Scripting Tool (WLST) command-line tool.


Note:

With a Oracle Fusion Middleware application installed, you have the required provider file. Skip Step 1.

To set up providers in a WebLogic domain

  1. No Oracle Fusion Middleware Application: Obtain the Oracle Access Manager provider if you have no Oracle Fusion Middleware application.

    1. Log in to Oracle Technology Network at:

      http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html   
      
    2. Locate the oamAuthnProvider ZIP file with Access Manager WebGates (10.1.4.3.0). For example:

      oamAuthnProvider<version>.zip 
      
    3. Extract and copy the oamAuthnProvider.jar to the following path on the computer hosting Oracle WebLogic Server:

      BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar 
       
      
  2. Log in to the Oracle WebLogic Administration Console.

  3. OAM Identity Asserter: Perform the following steps to add this provider:

    1. Click Security Realms, Default Realm Name, and click Providers.

    2. Click Authentication, click New, and then enter a name and select a type:

      Name: OAM Identity Asserter

      Type: OAMIdentityAsserter

      OK

    3. In the Authentication Providers table, click the newly addedYZ authenticator.

    4. On the Common tab, set the Control Flag to REQUIRED, and click Save.

    5. Click the Common tab, specify ObSSOCookie as the chosen Active Type for the 10g custom AccessGate, and click Save.

    6. Click the Provider Specific tab and configure these parameters:

      Primary Access Server: Specify the primary OAM Server host and port. For example: abcd:7777

      Access Gate Name: The name of the OAM Agent registration protecting the application. For example: AG1

      Access Gate Password: The AccessGate password, if any, that was specified in during provisioning.

      Save.

  4. OID Authenticator: Perform the following steps to add this provider.

    1. Click Security Realms, Default Realm Name, and click Providers

    2. Click New, enter a name, and select a type:

      Name: OID Authenticator

      Type: OracleInternetDirectoryAuthenticator

      Click OK.

    3. In the Authentication Providers table, click the newly added authenticator.

    4. On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, and then click Save.

    5. Click the Provider Specific tab and specify the following required settings using values for your own environment:

      Host: Your LDAP host. For example: localhost

      Port: Your LDAP host listening port. For example: 6050

      Principal: LDAP administrative user. For example: cn=orcladmin

      Credential: LDAP administrative user password.

      User Base DN: Same searchbase as in Oracle Access Manager.

      All Users Filter: For example: (&(uid=*)(objectclass=person))

      User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid

      Group Base DN: The group searchbase (same as User Base DN)


      Note:

      Do not set the All Groups filter as the default works fine as is.

      Click Save.

  5. Default Authenticator: Perform the following steps to set up the Default Authenticator for use with the Identity Asserter:

    1. Go to Security Realms, Default Realm Name, and click Providers.

    2. Click Authentication, Click DefaultAuthenticator to see its configuration page.

    3. Click the Common tab and set the Control Flag to SUFFICIENT.

    4. Click Save.

  6. Reorder Providers:

    1. Click Security Realms, Default Realm Name, Providers.

    2. On the Summary page where providers are listed, click the Reorder button

    3. On the Reorder Authentication Providers page, select a provider name and use the arrows beside the list to order the providers as follows:

      OAM Identity Asserter (REQUIRED)

      OID Authenticator (SUFFICIENT)

      Default Authenticator (SUFFICIENT)

    4. Click OK to save your changes

  7. Activate Changes: In the Change Center, click Activate Changes

  8. Reboot Oracle WebLogic Server.

  9. Proceed as follows:

16.3 Configuring Centralized Log Out for Oracle Access Manager 11g

This section introduces Centralized logout for Oracle Access Manager 11g.

With OAM 11g, centralized logout refers to the process of terminating an active user session. Guidelines include:

  • Applications must not provide their own logout page for use in an SSO environment.

  • Applications must make their logout links configurable with a value that points to the logout URL specified by the OAM WebGate Administrator.


Note:

Oracle strongly recommends that applications use the ADF Authentication servlet, which in turn interfaces with OPSS, where a domain wide configuration parameter can be used to specify the logout URL. This way applications need not be modified or redeployed to change logout configuration.

For more information, see:

16.3.2 Logout for 10g WebGate with Oracle Access Manager 11g

Logout is initiated when an application causes the invocation of the logout.html file configured for the OAM Agent (in this case, a 10g WebGate). The application might also pass end_url as a query string to logout.html. The end_url parameter could either be a URI or a URL.

Task overview: Configuring centralized logout for 10g WebGates

  1. Create a default logout page (logout.html) and make it available on the WebGate installation directory: For example, WebGate_install_dir/oamsso/logout.html.

  2. In your logout.html, confirm that the logOutUrls parameter is configured for each resource WebGate and that <callBackUri> is the second value as part of 'logOutUrls'.

  3. In your logout.html, confirm (from Step 1), confirm that the user is redirected to the central logout URI on the OAM 11g Server, "/oam/server/logout'.

  4. Optional: Allow the application to pass the end_url parameter indicating where to redirect the user after logout.

  5. Check the OHS Web server configuration file, httpd.conf, on which the 10g WebGate is configured and if the following lines exist delete them.

    <LocationMatch "/oamsso/*">
    Satisfy any
    </LocationMatch>
    

For more information, see "Configuring Centralized Logout for 10g WebGate with OAM 11g Servers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

16.4 Synchronizing the User and SSO Sessions: SSO Synchronization Filter

In Fusion Middleware 11g, a new component that synchronizes the container user session and SSO session has been introduced. SSO Sync Filter is an Oracle WebLogic system filter implementation that intercepts all requests to the container, acts on protected resource requests, and attempts to synchronize the container's user session with the user identifying header in OSSO (Proxy-Remote-User) or the user data in the Oracle Access Manager SSO session cookie (ObSSOCookie).

SSO Synchronization Filter (SSO Sync Filter) is an implementation of the Servlet Filter based on Java Servlet Specification version 2.3. SSO sync filter relieves applications from tracking the SSO user session and synchronizing it with their respective sessions. Instead, applications would only need to synchronize with container's user session.

SSO Sync Filter intercepts each request to the container and determines whether to act on it based on certain HTTP headers that are attached to the request. Filter expects SSO agent to have set those headers in the Web Tier. When access is made to unprotected areas of the application, the filter acts as a pass through. Once a protected resource is accessed, SSO agents in the Web Tier, direct user to perform authentication with SSO system such as Oracle Access Manager. After the authentication, Oracle Access Manager Identity Asserter helps establish a user identity in form of JAAS Subject to the container and a user session is created. WebLogic maintains the user session data as part of HTTP Session Cookie (JSESSIONID).

Subsequent access to the application resources provides two pieces of information to the SSO Sync Filter:

  • User identifying header in OSSO (Proxy-Remote-User)

  • User data in the Oracle Access Manager SSO session cookie (ObSSOCookie)

The job of SSO Sync Filter is to make sure that the user identity in the container matches with that of the SSO session. If there is a mismatch, filter invalidates the container's user session. As a result, the downstream application would only have to track container user session and react in a consistent fashion regardless of SSO environment in use.

Notes:

You can alter the behavior of the SSO Sync Filter for application requirements by passing various over-riding system properties to WebLogic. To do this, you change the Oracle WebLogic startup script and check for EXTRA_JAVA_PROPERTIES in setDomainEnv.sh. The properties and Sync behavior is shown in Table 16-6.

You cannot enable the filter for selected applications. The SSO Sync Filter is a system filter. As such, it is activated for all deployed applications (the URI mapping is /*).


Note:

You cannot enable the filter for selected applications.

The following procedure gives some tips about modifying the SSO Sync filter properties and behavior.

To modify the SSO Sync Filter properties and behavior

  1. Disable the Filter: Change the system property "sso.filter.enable" to "false" (pass as -D to the jvm) and restart the Oracle WebLogic Server. This toggles the filter status.

  2. User-Identifying Header Differs from Pre-Configured Sync Filter Tokens: Over-ride the SSO token that the Sync Filter looks for using the system property "sso.filter.ssotoken".

    For example, pass to the WebLogic Server jvm in the WebLogic Server startup script -Dsso.filter.ssotoken=HEADERNAME, and restart the server.

When you contact Oracle Support you might be requested to set up debugging, as described in "Setting Up Debugging in the WebLogic Administration Console".

16.5 Troubleshooting Tips

For more information, see "Troubleshooting" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

PKYYPKfp@OEBPS/apusrole.htm User and Role API Reference

D User and Role API Reference

This appendix contains reference information that you will need when developing applications for LDAP directories based on the User and Role APIs. It contains these sections:


Note:

IBM Tivoli directory parameters are the same as those specified for openLDAP.

Microsoft ADAM parameters are the same as those specified for Microsoft Active Directory.


D.1 Mapping User Attributes to LDAP Directories

Table D-1 lists each user attribute in UserProfile.property and its corresponding attribute in the different directory servers.

Table D-1 User Attributes in UserProfile.Property

AttributeOracle Internet DirectoryOracle WebLogic Server Embedded LDAPMicrosoft Active DirectoryOracle Directory Server Enterprise EditionNovell eDirectoryOpenLDAP

GUID

orclguid

uid

objectguid

nsuniqueid

guid

entryuuid

USER_ID

username (see Note below)

uid

uid

uid

uid

uid

DISPLAY_NAME

displayname

displayname

displayname

displayname

displayname

displayname

BUSINESS_EMAIL

mail

mail

mail

mail

mail

mail

DESCRIPTION

description

description

description

description

description

description

EMPLOYEE_TYPE

employeeType

employeeType

employeeType

employeeType

employeeType

employeeType

DEPARTMENT

departmentnumber

departmentnumber

departmentnumber

departmentnumber

departmentnumber

departmentnumber

DATE_OF_BIRTH

orcldateofbirth

-

-

-

-

-

BUSINESS_FAX

facsimiletelephonenumber

facsimiletelephonenumber

facsimiletelephonenumber

facsimiletelephonenumber

facsimiletelephonenumber

facsimiletelephonenumber

BUSINESS_CITY

l

l

l

l

l

l

BUSINESS_COUNTRY

c

c

c

c

c

c

DATE_OF_HIRE

orclhiredate

-

-

-

-

-

NAME

cn

uid

cn

uid

cn

cn

PREFERRED_LANGUAGE

Preferredlanguage

preferredlanguage

preferredlanguage

preferredlanguage

preferredlanguage

preferredlanguage

BUSINESS_POSTAL_ADDR

postaladdress

postaladdress

postaladdress

postaladdress

postaladdress

postaladdress

MIDDLE_NAME

orclmiddlename

-

-

-

-

-

ORGANIZATIONAL_UNIT

ou

ou

ou

ou

ou

ou

WIRELESS_ACCT_NUMBER

orclwirelessaccountnumber

-

-

-

-

-

BUSINESS_PO_BOX

postofficebox

postofficebox

postofficebox

postofficebox

postofficebox

postofficebox

BUSINESS_STATE

St

st

st

st

st

st

HOME_ADDRESS

Homepostaladdress

homepostaladdress

homepostaladdress

homepostaladdress

homepostaladdress

homepostaladdress

NAME_SUFFIX

Generationqualifier

generationqualifier

generationqualifier

generationqualifier

generationqualifier

generationqualifier

BUSINESS_STREET

street

street

street

street

street

street

INITIALS

initials

initials

initials

initials

initials

initials

USER_NAME

username (see Note below)

uid

samaccountname

uid

uid

uid

BUSINESS_POSTAL_CODE

postalcode

postalcode

postalcode

postalcode

postalcode

postalcode

BUSINESS_PAGER

pager

pager

pager

pager

pager

pager

LAST_NAME

sn

sn

sn

sn

sn

sn

BUSINESS_PHONE

telephonenumber

telephonenumber

telephonenumber

telephonenumber

telephonenumber

telephonenumber

FIRST_NAME

givenname

givenname

givenname

givenname

givenname

givenname

TIME_ZONE

orcltimezone

-

-

-

-

-

MAIDEN_NAME

orclmaidenname

-

-

-

-

-

PASSWORD

userpasssword

userpasssword

userpasssword

userpasssword

userpasssword

userpasssword

DEFAULT_GROUP

orcldefaultprofilegroup

-

-

-

-

-

ORGANIZATION

o

o

o

o

o

o

HOME_PHONE

homephone

homephone

homephone

homephone

homephone

homephone

BUSINESS_MOBILE

mobile

mobile

mobile

mobile

mobile

mobile

UI_ACCESS_MODE

orcluiaccessibilitymode

-

-

-

-

-

JPEG_PHOTO

jpegphoto

jpegphoto

jpegphoto

jpegphoto

jpegphoto

jpegphoto

MANAGER

manager

manager

manager

manager

manager

manager

TITLE

title

title

title

title

title

title

EMPLOYEE_NUMBER

employeenumber

employeenumber

employeenumber

employeenumber

employeenumber

employeenumber

LDUser.PASSWORD

userpassword

userpassword

userpassword

userpassword

userpassword

userpassword



Note:

username* : typically uid, but technically, the attribute designated by the orclCommonNicknameAttribute in the subscriber's oraclecontext products common entry.

D.2 Mapping Role Attributes to LDAP Directories

Table D-2 lists each role attribute in UserProfile.property and its corresponding attribute in different directory servers.

D.3 Default Configuration Parameters

This section lists parameters for which the APIs can use default configuration values, and the source of the value in different directory servers.

Table D-3 lists the source for Oracle Internet Directory and Microsoft Active Directory.


Notes:

  • The Basic Binary Attributes include: {"photo", "personalsignature", "audio","jpegphoto", "Java SErializeddata", "thumbnailphoto", "thumbnaillogo", "userpassword", "usercertificate", "cacertificate", "authorityrevocationlist", "certificaterevocationlist", "crosscertificatepair", "x500UniqueIdentifier"}

  • #config is extracted from the meta information present in the directory

  • #schema is extracted from the schema in the directory


Table D-4 lists the source for Oracle Directory Server Enterprise Edition and Novell eDirectory.

Table D-4 Default Values - Oracle Directory Server Enterprise Edition and Novell eDirectory

ParameterOracle Directory Server Enterprise EditionNovell eDirectory

RT_USER_OBJECT_CLASSES

{"inetorgperson", "person", "organizationalperson" }

{ "person", "inetorgperson", "organizationalPerson", "ndsloginproperties" }

RT_USER_MANDATORY_ATTRS

#schema

#schema

RT_USER_CREATE_BASES

ou=people,<subscriberDN>

ou=users,<subscriberDN>

RT_USER_SEARCH_BASES

<subscriberDN>

<subscriberDN>

RT_USER_FILTER_OBJECT_CLASSES

{"inetorgperson", "person", "organizationalperson" }

{ "person", "inetorgperson", "organizationalPerson", "ndsloginproperties" }

RT_USER_SELECTED_CREATE_BASE

ou=people,<subscriberDN>

ou=users,<subscriberDN>

RT_GROUP_OBJECT_CLASSES

"groupofuniquenames"

{"group" }

RT_GROUP_MANDATORY_ATTRS

#schema

#schema

RT_GROUP_CREATE_BASES

ou=groups,<subscriberDN>

ou=groups,<subscriberDN>

RT_GROUP_SEARCH_BASES

<subscriberDN>

<subscriberDN>

RT_GROUP_FILTER_OBJECT_CLASSES

{"groupofuniquenames"}

{"group"}

RT_GROUP_MEMBER_ATTRS

"uniquemember"

"member"

RT_GROUP_SELECTED_CREATE_BASE

ou=groups,<subscriberDN>

ou=groups,<subscriberDN>

RT_GROUP_GENERIC_SEARCH_BASE

<subscriber-DN>

<subscriberDN>

RT_SEARCH_TYPE

#config

#config

ST_SUBSCRIBER_NAME

NULL

NULL

ST_USER_NAME_ATTR

uid

cn

ST_USER_LOGIN_ATTR

uid

cn

ST_GROUP_NAME_ATTR

cn

cn

ST_MAX_SEARCHFILTER_LENGTH

500

500

ST_BINARY_ATTRIBUTES

Choose a Binary Basic Attribute (BBA)

See note below about BBAs.

Binary Basic
Attribute (BBA)+
{ "guid"}

See note below about BBAs.

ST_LOGGER_NAME

oracle.idm.userrole

oracle.idm.userrole



Notes:

  • The Basic Binary Attributes include: {"photo", "personalsignature", "audio","jpegphoto", "Java SErializeddata", "thumbnailphoto", "thumbnaillogo", "userpassword", "usercertificate", "cacertificate", "authorityrevocationlist", "certificaterevocationlist", "crosscertificatepair", "x500UniqueIdentifier"}

  • #config is extracted from the metainformation present in the directory

  • #schema is extracted from the schema in the directory


Table Table D-5 lists the parameters for OpenLDAP and Oracle Virtual Directory.


Notes:

  • The Basic Binary Attributes include: {"photo", "personalsignature", "audio","jpegphoto", "Java SErializeddata", "thumbnailphoto", "thumbnaillogo", "userpassword", "usercertificate", "cacertificate", "authorityrevocationlist", "certificaterevocationlist", "crosscertificatepair", "x500UniqueIdentifier"}

  • #config is extracted from the meta information present in the directory

  • #schema is extracted from the schema in the directory


Table D-6 lists the parameters for Oracle WebLogic Server LDAP.

D.4 Secure Connections for Microsoft Active Directory

Active Directory requires connections to be SSL-enabled when setting sensitive information like passwords. Therefore, operations like creating a user (which set the password) will not succeed if the connection is not SSL-enabled.

PK( R$C$PKfp@OEBPS/part_apx.htm) Appendices

Part VI

Appendices

This part contains the following appendices:

PKTب. ) PKfp@OEBPS/apreferences.htmJ References

H References

This appendix contains references documentation useful to developes.

H.1 OPSS API References

The following Javadoc documents describe the various APIs that OPSS exposes:

OPSS APIs

Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services

OPSS MBean APIs

Oracle Fusion Middleware MBeans Java API Reference for Oracle Platform Security Services

OPSS User and Role APIs

Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services

Oracle Security Developer Tools APIs

Oracle Fusion Middleware PKI SDK CMP Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware CMS Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Crypto Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware PKI SDK LDAP Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Liberty 1.1 Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Liberty 1.2 Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware S/MIME Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware PKI SDK OCSP Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Security Engine Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware SAML 1.0/1.1 Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware SAML 2.0 Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware PKI SDK TSP Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Web Services Security Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware XKMS Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware XML Security Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware Crypto FIPS Java API Reference for Oracle Security Developer Tools

Oracle Fusion Middleware JCE Java API Reference for Oracle Security Developer Tools

PKPOJPKfp@OEBPS/img/jisec_jd_001.gif0XϧGIF89a>匲89;Gmk􌣻qqqJWeM\پ")؛XniOs]qEHK!?DIruxgtzz{YYYqz즴qڃ͠MmBbډʧQVXPg}../Ѝُ酝훳Lic{O_o!,>H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗0cʜI͛8sɳϟ@ JѣH*]ʔ`PJJիXjʵr3i-[fm[Y=EC.x28߿(J0C(NС7zLZgӪu Wnw`Q 'Vܸd3*b7BK 8q>EL˙׺s]-mZp«;~ [6m۷ wӫ=:;.i֡^uwڵٖxv^%`Kig^Vjav7wG`d({%hV fx؆qם 7n)iF j|G!uو!=(" y`J{.F] ,r%pZ=O˚0w)Wzbx%a&AcnVs0sxs"~Φ#T/bEcXh^.*>Nf"z]eZVei uNGuvDCǍT# 8-|ŀOZqSyA1 :>;hݛ'o\0F ؁!THrT2ƌgYedwu 5.֥ g]X9ʻunL!hU:HT9N9n|QiB1)at7{Rf,d =Pɛguf}}S\k8/T˳8ЧoOk_7ɋ~K`O𗜟uT~ $$y#Zȇ+'QHz^wA/gHy4"]GC #A/yh&2 P*ZVEx7DH-{HLI6p x ʌ} d BꌐLF* )J̤z0L (GIRL*IU򕰌*I` |ȥ.w^ 0IbD/Pˡt3iR!ּfOMp9&8 "q֤D9eNps/y6 OГgJL~$d@9fҠ@\hCɄd .~u@EY2@F0R!:_tLj%|0L& ( Z hZ22YTJժZYJծz\%N Z!hMZֲxbp99G R} nЃ5ΠMZWZHd ]ߒW40nB|ic#v7qBŚh=FVe^¿]|$ (Iΐ+3Q>(f7#֏HOX`5xي\6e^kqv*(8- qk:u([BJ.D/'|V5M^4[p0R;r7%~)lZ nQd}Վnk绕!-)XI٢ exY͖dCFlxd>@;%ΗoyL!gy[ư]&Ws2ͼ*4DVVћ.;%M|2; npL6O̓.n_V/aF0EUR6oz`9iEGrkdN{O>kwK\Ħ h=vqm"#~?B[ z{oE,b-Wj`Ś,MnVCȷ (0`zF\ظ&uqrx+Y8,6 8B&'b cل{{`8R#.+?`q Q {gq{kShp-⢇'8 *F=5aw؈Ÿ`! ȝ6 `3 bu pGxXiSh(AxB'|>N$4N {b4 "!@X us\8Y%@gP@$K(+_cP@D3"0?PSCa>`^`'/LVtB 7sV` PRs'qq  `qz` q pϠu@Tp@ s gp| 7 0  T %pNy@uEp0Ȁ ` 0`P7`]p'iC|'sph5 0 spGx' VVsg OgiX`'8z&$T0o ~'pQ3f *P 1 q0 @PV w `q7G ^v  0 C 0 p0g = @e nrp3V c4pD g_.7 '@B1P|s ip Pt` PV gt Oo;x Ӱ ̀YEp)pN@(BP T,̰p70 0 hfUqG4=G'n  ER (l1 0S` qa 's"sY4p`ȊP[5Zbsh t#ɒ$VqV!t ui<g0sTpg@4g' K>Ry, `VY1Sl,`RVm6qUq, z P wp ȷ \&' uPE0H09 #@27,Y1(j cq|@wV$y}e`@0cPP& BW_ #f3pkE̷D&g"tkz?B.gB13Z/ε+reVj}&QMqVpзZ%ն?0-g'mAZ0ѿirh?r>5X# X}e8Ad'YS>Ad°gA,,cFf!LJ,?ku<^1c˒[,/L\N k־06Yֶ^`&fW|[.A#/]_ j5,d b+kǀ7oLqi~>rjh{ē=7lȩe?&+\FlKɕ|ɃsF><  YS-U^ x>mʒנmjvMjP֌Eא-wMٕӗ>.LӀlgJl֥}_ت0\Mz D|Ҵ ?]FM=ڊ]m.y]̐(۲mABd]ɸ= }݉Ԧeލȍ]{` ے|mփۼ۹L-m | lg ` `1/a aa` p, IN.8 .` P-]*qM} *m57 zȀ6 3pP`@@8Q-pP *.Pqcbf^hҽD ]iݠ1`ZXsj<]@h~z!^)pЦp@% .yN8`8Pڱe>'QSln~0%m0sЮ2XS fA`pNA 8P~`~ 8`g 3%ngE Sr/.ܰƎ5 3g !*i a g@sO.P <>Bޮۅq7`` pAj]:R]!]f?_)8n( {L` |_ ?o"mk nzrp)qk=۟  9 O  %} rAA {`C%NXE5nG C@AQd )UV C{yܞ6 tOQ3S70cƨ)S*xHF*lm4S֬YBp4JKB%Jp!W_\x%_ C&\aĉWJ/%Y&O?5aRN14մT "ٶiy[n^~oq)'ô\͛o,ZiE6Vׯnkvnܻg{?NryΟ'ٺ4;Ծ5+̫ 3*B 7X/?N Tis6R sq/,LbH" ## cI&t'pG)J,-IK0TgL2|L44`M64`7\fN:봓w xO@}A8XPDUtQFuQH#>&RL3> SPCfjx'72p tUV[hPxݟQ~xވXڢeSi~$ Uj[>r!b孹6pv,qfpm!Iʥ#r>u~Y:Z٬vi m['Ǵ~5R]Z/u :ls:t}X 9p[QODXwaCv?C .(?`?>"( [Xx|.Zpb~Ј5zأ`2lgr]N|;avkgE:d0]'8EP.`uePdcBPFrt3p - 뗂] &q ~ d1t:"S9Q46{ dȾI\! M8O[X >$J,JR"_ *7FG0\` ՠ.yx|8kE#U,5dIwr ݝp |\8?k}E)s ZxlǕݤhжI x[jdʍ?5#)pV ր5CB0JUF46hSsNu[t>Ȁ C 1թcT 9UҔj'A Td^ $ Vc]YӚVUo+seU}Yg׿~;ja >,FKelgWS ([Y.ˮmX=Z8vUi6:}k\ [^ĬTq{\JRkTs5\nRk0x~\(P)]W%oy{^Ww0PEs{_Wn@5ٶXVxk]&#-i%{۫t̗޳\Wepg'` pahxb*Q\-v18<'K֤pXqw&`Xdd9KflLm#.emz22g79Q-2HYkHW*=sePD;uxx5Ӝ9I+V$wd0? @HX.)I "s HHpJ@0X1;jtS%>>\`ݠ&AmkҘ ʠ-p+.OimAp:L"0BUs搁 0|{Y~`BIw_Mg k]3Uݦ>b յ:[@@LHOtŰPb9 ,`& F aIltQi@ghcYv4WS~ `țaWρч)8C b0vQ(zMOßˈ'r^'GsKqFb뎔[.`EE|s0G考=8Xo 3(2$Ա1Rc[Fi ~*eLRqBݧz-r Xv<07":>K 4Ayڴ33v<) +sr ;{]0%(?Hs(sD>T0d>ەRѴZq ? )#:>&@v#pJcUK*lA(: ]1C* 12 ; Z>`>6ɕ9C!2" UKC_<OhFiFjFkFlFmFi\CFo GpGqGdEe.^>w|GxGyGzt.ȃ{G|G}G HH,H<t,uC:d`!0 ILQlȦYfHHHHHIɦ8I\H d9II JIɟ,\I:Lttʧ,4IJBb^dG_ʢJCK,8˨Lː\K䘬J|˯˼KJ4L RLLL MM(* MLMDMh$+ٜMڬMۼMM$bM N,ΏLANlβaNNN΍NoNUN OO,O !OdE>@1hO|OOOOOOsOOO-P-P&ڛRЊb rPnnPPnPXPXPWAA"1QABQ'RQ'bq&MP} ( - !PPQ M ]m"Ş#*+e,u-m.m/0M1E2E34=556578-9%:%;XcUUXK⹕UVd;ce~d^  ( K^ebaO[cR֍8S&0P-Ub]dZFQcO^ei&(6co^fhf*fTvA _am~degk(X}V\evd>慂OdXi.-$ngmNovphg k7~\:\ၦg2猖]rHjdݕe~bgeWi{ ^d>uهbhh^hƀN k؄Kjv^&dkyH^ r@}>jjl.incz&0p㭎kCllnenmvŰ"F^U^xkmَlp7^Wecf䝖z6 ^0mN^g϶6I0Hg#fmnl ina6lgpn._>a.pF_iiDl#<6ވlpFvgvj.o>o6 (}Wڛf~l7n+vBNjoj\ _r&nrvpm-Z&o 'n qOqX( m?sPVs-gs.&q 8 %`E.>f/nǀ?' S#[;qFnmr?I_Lo=lcfsI@(urN.sfu>I'G0o.>c6NI/Z'>u߯0v<'qv7obtHCGub oGXGkYb'u8FtVu"vm%j/ЁhхpDkod,hPqa boX̮k"6raXX$7#%XClq+܁fJގ$Zfq EV%١cQbPIƚH="嗑^n7#B"SeDP Z$ة{FӪQ^{ID(`GhZ-h>f(`Y6 bz,ҎYcz8B+E]qJ+%i_ wn8 * .fmy6s|28;6PvG.Ld`hK]@LP2ꨋlkAZP~ +Pѽ 0.Jt TВ r-le&jV=_oWQh~̽Ms3IK3 Fd4"f^th|p /9q;q5뾲{- ұxWA IؿM\B'| @D,aK9o+h Jܴ áL1u\a>f( RәT3H}q`pnR0 #jJs9 J=#Pgpp )~[AR+>-;\tή @(L}W9GI}DA- P&[ ZZwõ! Edؽ*(uA jl ,hF_V4asRڦK(<-"vZ,l#-Y N8GˎJ\E[,/8xp%d l"[,IA*^{Q~xN@x+Jp>7׺uOA}v{{0 pR@ pބ A o÷i9O&]o1M^{I^'mpxp>3sXUִkt]D l3>Wx@y\>wHZAu*Zx+Ұ3Uάˬx}䶀|&_y_w|]Ρۜ ^(Y!=$߂A^b՟F!^!j.5P6L" V"ǡ 졡&' " _ -B$Avŕ] fJ!Zaaqa`]a1 ,7(:LZ)E`_>:N#5~؆ 8!KV b""BG^!93pc<4C>գYba>? Ձ`AWMYI""DJDʢ!da$"I$"dY}!J5cLL.e52bNv r $Z$$tA4 D ]A^Rd-NFu!H" CU h&#ddeF#M^5%&Ep:&VRj2%()\\Ul ve"Xf?pZ"}@6\+:]*2%_fF&/&|9@/CyI =4&>u3'Zfg9xpOl"0 ~%P&f;d'%nYLj兺^~e rX'@ A,=$$ s:P hC݋,V_Va.Z`Gz]3pchNʧ$fP@$M~E4&hr)ej.ef3\6  8%)onh'e5eS+"\  vVg^ve`{=AaW-6l5'*46ҧN0C@^j/R*AS>H3hah &F+pVq .\3A-y6 CR'J:+^ᤶf}g`5D29{!`(flB$"yO.4lCՎh&%;*bƒ8"`L*7c)~"Yi".$(2h4plΨE"`+0H%00WZ 4_%$|ڭ%|B)l> f9mj;֭TB|bmC⣽i(f ̓(=[ݬC5n,u6*ngv'V ?tYݴ)B#ͮ9,V(\$hO8i@HB@<,/m:ZRF/bX"h@ @V)4*観X( 5%t3u./x@# ^kV0go x o gL*<%X9p77}V' DC0C ">U K A0iףA6ȩq#Ra聶@2bv:4)7 t϶p?mF 4-=(P0恛)__3ɪrCtK9Ӂd;`^@qxI8/ø֛Sz D+C6칞B6&t(y+03iYZUK1JO|!X24o@@+P5MbujW e3N%" (!'c>-r%/3^74tNgF @4/"GcsWy$׻3m!3?$20jZ3S{ >N޽ >44oqb/w&3wo5wKi;aHɓwK$;|å< U5C(;<|&18**bt`>F<3 c1J="w|7%Ȼs6& ٝ=Oڳ<;{2Ҵc;_4 <=,}N ǴC,CzG"l+2{!HzN*hCwn׳y|VCm7?>ü~L%]e&+!RYx*A #lh@Da -t]B+Ytey:*K!H@$ [@pt@( 0])dC"Y  ;ɰRʉ*@X bZKD6*؆~i5 L{WR@X%ݡS,A ])4Ҧ H BN6a `Qx#Z@x+R( Ƿ%# ENþ b(RLVL*?'x Jih5n赖ز=RxE@JB TJ*q`lZ'z)SN梚ʺ(z jD(*N8;Eb24 Ϯ#4 3εEK<um~ 0'3ƲN3' :Ѣbd-MD%"hbދoo [$pJh&#$ECLaM 'x (2u*Ҋ+,Gc-x.ɇIaD虒<[O 6UPMNN5HS36]8 %6aF0<+Khc .Q3S-ӁٸT]4emO>?UU,UdpVm 3%AVeDD@iEeWlEJjmLGzd!}{)zitn%&O'ӗP~wL,IFmVv9P`Ssόp':Yyn4] 5qTGڞW@Xr"Z#Lm> I (7m]J"VB9UkjkvtߊrᖸgZNfWs/?'<`eB͙LYXbpp#(PA.PC2W?cBF'8!ձ}30! nLT8#Δw ZPgLIS@QzyPԖpRbZuAyZ7ʑxDHD ~UP\*ς~נ&LK  B=t7ȁ4!oV -,G!snpDkaE0@6lX!H%$C.h6*N-}YGvM 1Qє9X0ЛT DˡAҪ K(А0b"+5IY$fM-נ@#yӌg0Ws:? 'c#BB IȇwJXm@ dB7K.mX" Iu V ,0E#TRdž*)boBH;WhMDdd,p)6A/r4jXM]@  雤`AO/;)z<` d|k?j_$!80 ܱU6dh&+"XKHD.4`0eOK-!'𰑊 YM$E 4 l`p$nGX/QHO-#8[7RXaȆ)p$PuÚG qW~^ŁXH^cbHq|:&Fa`{J./F#Q$4,k)R2.@7 `xj-+ / Xd4JVhFњ$P,"P: |h0D f:e>,kkPT` J 'P,"04 @J-(.t,hG&9!O )] i:LЮ  * 3A8K͢*u-VjHxaP@g4l$xO nKKrKl'[ ;І }N֢֚o _pH06q rpl:KOyR }`l@/ϙT |( 3HH* R3UIR @r4 4k)Q@8!2q62n.F.si9 HA K0s00y0ï vr;׼2Ŋp,g $`S43# 80USn  6U0?M6QwrSxv%w$:I>}89uR91|s|$4:..*`IIiA;o )D4*D@]S*;1+5RdPS G`rFR66SERS7.tO!C/4'C-Xl: ن.n@qZ@8L ;/3iP rF#=r>OYGEP,:+7%mu%RpI4J1uJ_m.aTT ~C;Y5D=R ut BSUsU,jFqAZ5f?]6,HUsJA @ v%8V'at6l:U%`a 2_)3 <_ srXeIsRtTbY|a- Yt` t`u`e ,c1cG9J*K} Lh&F`RCDeU5RAHIR!ՕNhò#]~k-t$YY?UxLdז%@[/vRS#l=-sYV)v]]NJD]R@ZSoVEAWŲ pʡwm9`e qӳY;auYB q=[9S {]w EknrfNyI)Z`z=Ng$w&qaJ2rvQqW{÷` [G7l D@8ab>@^L[UM1p6s`pKS1Q*c耀?-jUrm$RcX`H}l&BB svGx<N8$a8@WBn\`z%WH)wNM+9=`Ơ d,,XהqPCٕn4ў`@sy%`B%afX g9h B`Xcaonz'YAn9=wR`\ tmql-纠aY`6L)ҍR oz%ג9Ơ Z@ZR$!< ~B8 5S88 BPaAZgq٦e5zUਉA9I`C9OS:B)٫899뺮ahv۱#['+۲/3[7;۳?C[GK۴OS[W[۵_c[gk۶[@z % x۷% ${%{Lz`# %{{%Y¼8@;w;% U5r%{%L`a { ʡ0vL`%[j``!˛%8  ;@=\[|v7\99ܦi| UC vA#[7| `1![i|%\jaZWC|_ܱ\ЭS |Y j\»|́+\W"W ܹ̑9@ہ6 =[vaE<Γ{|bK=[|e`7@Û=oZУ|!;C!2={ a\E̿ݦ `{1>åܱW<@¯%] ˙ea3|{g5aWBMT%Z3;+>{y_u?[ʁd%sA`{M }Εcb]Y];o <0… :|1ĉ+Z1ƍ;z2ȑ$K<2ʕ,[| 3̙4 kڼ3Ν<{r ;PK K5X0XPKfp@OEBPS/img/fai_11g_resource.gifM GIF89a<3f3333f333ff3fffff3f3f̙3f3333f3333333333f3333333f3f33ff3f3f3f3333f3333333f3̙333333f333ff3ffffff3f33f3ff3f3f3ffff3fffffffffff3fffffff3fff̙ffff3fffff3f̙3333f33̙3ff3ffff̙f3f̙3f̙̙3f̙3f3333f333ff3fffff̙̙3̙f̙̙̙3f̙3f3f3333f333ff3fffff3f3f̙3f,<=6,8„64(Qaň -fFN1E#OJ%[t&͛3s'K0 JQ:sҤN6-*UiըLf V]|@Y=HZpݶ}+7.ݻs[/޽+80ÃV\1Ő3~,92˓3[\3͠=s,:4ӣSV]5gª66۶sޭ7߾.8Ɠ#_9ΣC.:ֳc߮;Ã_AF KUß/>߯?H& 6FVHfvl ^YF{-b0h8֘#<ި=c@iH$LM.dPNiXV%\^]ne`ih&lHm#uw瞰٧砀*hhh.褐R*i^iZin騠*jjjꬰ*k޺i59z K&6F VKfvކ K榋y ǽoTo ⛼Fo +%& 0Kl0G[qoLq"{<2$kr+.nj|&\-|:30tC 42'J4OK2C=OԀ-65]bTڶj-sMv uz-߃kn˜q-o>@.PBmQٌgj9}.z{^:覧꣫:맿.{촻^;;.|^<'+Џ`G:1ΐ;$>EyL$9HR$$7N>ғ#CRLe%9iJUb\(eJZe-uyKMҗf/aJaK\(W E,^Y]2mz7)rD8uӜ;)z<}Ӟ?)ЂE@Ѕ|h"N/eȗ>*RDi Uєt/m)Lg*Ӛ1)MujӜt?)P*ԢAE*QjԤ:uOm*T*ժ2IV'?q~?\%9lLr%e39w~?׹ONB:ϕ>t;l0'h{ϸ}[EıDjeOO8毗dA6v|d9as;jxr@x{km[6/giQG~]q~Wt jfb9{ s= IڳU!ogC#0и\ =6t~m[{|Ç/nR_'5ׯwO־ۨ|q=-fprE%_Z>4A pkZ'R>bl&xGxwy|Ev!n'wv7k+8?x$y}%y聅lVzBz4EHdIuNO؄P8RXueYȅJ]bd^ȄgiHkfQ XC0c0nu(x)wxd|HS6F^V̔PѰPʰ LoWw}|6h&q hz6|'~(|(~^6~ q|q tG'OGHttȋttĸhhǨX}k!Xט}uu$2{a6 ؈ZgpF i5{W9|lv=lIlHx35%ڣVjYD:FEG IʤKJ"cA#:4C U{ZLe`  pv@ I`h8oXqJj(u:z|zvʆx{*} ꆅ:mJ$?Iv74> I` | Π ɞ9Ꞵ* 艹jʫzŪg *jzպڭj_օ=g3 ( (, !"Zzw6$  uTJM:OZKkv= M` 0Ģ"د/.;0K2[8{כ0ATIkRzjP۴QR[T{š̺Ɋ\]aN+I^jkkmol;nKmֱz˱|~뱀+۷;;`\*;먒 {깗Z۹K[ <Zf[d;kkc` +Kk%Ò +,k,Ӌ'K٫'۫K ;[k鋽۾ +Kk竿˿;| ,<, L<\| ya+*,.02<4\6|8:;.+H^݁MOMݽ2NQԠM3LaYnI>- ű>_ qڥ=BϽdK 6-s.0^-a5-`袮jA-6Sa>M7܃AGn䇞^9|e^ƭX.a4Nް>Om~fymޞu.^9~>n>nY\fr0^^t~ uhkqZ^nޫ-/t.E~*KP+4>t91D+}昭a~~?RŒ`0jXoߞW`tS_޽ۥۓkxp/y ~jR?D]j >s#[/6R?6RQCo/oӵO/ŏoJ\_mُ(]_/?_O ~MoO A@ RV@ >haD-:(1cō5~cH#MvD)2eɕ'Ud eL3m)3g͝7u gPCD*4iѥGDhP@ZVWf5lWeŚ%{VmZcݢ}6n[uڥ{Wo^s7p_&|Xqbƃ#~8rcȕ%[,Ԃ~:臤Ag4]:ԭYF {ulڳ nݼwoÍ G\y̗sӭK]{ܷ_wߧe>6C/^~x׿orl* 0,DP:P ZP!|pB 2/C4pC;CC$qDKDDSdqE;0 % KwlG1H@ z I%ZR2J!J*2K,Kl2I&ofK-(Jȃ.c337? :ͺ<+RM?4PA%PCE4QEMLGF'RK!#=N? ND;HUפՇZUYWY]u)W_kV`"x 6YcZ`SZ&ÔYeu[n6\mȿ?Au)\B]?sN?s=3_x|^v_Bw)sb5-40ъc?9&4]v!TxW6 I59f'@gl>ԇHhi!Y$(፫PgZGϯ B{))b&V(bnZ%X;o1MHRx +}_?vb;!x׫'r5r17bEGG7;t&=%u֓u1ǽ;tuc_1gs{7r^;{5tu=س|;' 43?Cz;}ɟګ6h5̀^ 3Iv `0H ^=qFC#6*mL[F>RM}tB'San$Dxe JYb_`%ƫr0@ib_C8rvb3woZPbpcX<88== N[I 2DrP+a$%'"+*9&ƍm0VPB <өJIiũp"-XGYudK 4&9BaQ%6mnۿF5O!fNII8Gӝ};rE`s# )eR0HBQgP_s 8MpuJQ04gH=l\:Ci&K4"7Gs5L Fv['Ҧ*z KՙP*0_ %bCSgE̥"Ψ[׷LeFĊYѺWAR~ҕ2$̢a f@fTST@XMI&Wٔj(0lhIVKUKֵ[I7yspmZַɭmm;7P݋n1}]n]F7=j@k\vw't+&LCgһrʽ텯zo~_׿EQK׹5ƫ\`K2-"] Or]`c0=|aGZmj=$%Dh 8o+Ʊub(Ilk;Y|hVZ ɑ,rldRR~lv=ԋ:kS*g=[О>xicaAST44uQm3Wz8A3䁖զ.k]z nMלk-9urg26t\"Ӹ͕1_ֆН-o;K;c@a@l @s> 8, |Aٿ@,p{Aj|A 3=ݳ= =ADBE ,BlB"d)'=N>@ \@.|L0 ,.,-C:BA?;tADGJ "34$N\IID/\CSD-<4KtQW<<[A><]4D$_DF^LD?=FB+tddF*XF:\*lFjt+k\Fm{DJ,pEUd@F$LEN$GTdGq\k[s ZtyGM^,0G{ H4HcGyܵz$|HȝF@vGuHȈtDÎ,w4ULV}EƆIIE$Ƅ<ĐIɠJ8FmƤFF#_ƥʦDʩJF$8Hʏ4|#Iʓ˲xɖŶKK4ʃK8J3K2̿$L!˟KLE4ʹHtȄɬKɬL|A4˴JtGLIL$4D͔۲Ǽ؄ٴLڤL۔MɼIJDTL<$,N\LJT|FNnNtNNLW9T U`-jp|OtOXOOOOP,P4= Pe } u RMLO  KFd;uB <ѬHXшNReLM QjҒBR=+elG嫲"9:P&=.]Ot9UM̙-؂RAlK7=R@*3 *2'^zB&DIRѭJmQ,ԆM<؂HʠxOB¦W WSMU:ۥ'p%*X+YR6*# >Y[4)c[FRW}UQJɭRʽ~MSzRE$CXF :,(* ҍ\ɗ=-}B\¸m6Vx'{٭Qa5-Vm":SkZmޯe!+}qqW +VYEۍ]¥YDM6%)(U*E2d"C]ΨB*$(ǂ*"*2ihaC2;(3éB&6BJ ӉWŘQmӧ"RZ#nZkIQyQޢyh%߱*a%3^%]R~c`T;ƻK^<0=ф`D>FUdL=Xd6I&GMLMf`">b%f8lc~DEU&eQ^bVR=YZ[Fe[e\N=E_`&DfcA]N\effhJ QWneU$f:nveofl&gFggVgiNgvM cfdygyb]TVGdN&hMh.O>hNhehjgqerhhpGYns9(^gv^g}z}ii#SbVij^f1hfjhhq6g.j&jx^뜶>k~^f&<0񌷖븦kkk뾾kַmH?ւ)ЂFN99VFflʆlǮl̾lƞlTlHv&FmO^Җhwi*mnVn.?m^jꨞ~jFb:~ jp&6FN^VfoBxkoM&mP&p.>pN'WpOnw& piN pT7GqDOl-q.mqDp#n$W$g%w&'(r-ml -n.jP; ڒ-Hy 57_H9osI p=>?@t.CrDoMVɋAj?hLg,G#t%$uPtQ?uROuSUB7eYZp gk bތtu^ߌab@vd/`0Vi_nhgjv϶pNfpq7wnm&׎ؾ@tI'Hw|yw{{:,LWx?XgPxx|xxx`w/?O.g1n0oy1~+ JWIyIz`uOlIupzMo{!%zR tVz}_{MLO M_t\oG s|7xtI IWx x7 :?mpB ?mχ,ҷ ?|t'}?͟}q,p[[}ZooV|`t_7/?~HWz􌯆7$~o%~?SNȻEjU „ >ئÃNH S`hQb)`|A!MV RcŁ/~Y5?gϝ$:O:iөQwN iФLrMgTLQYM-ĶreKw.Zjw[a EXcv!O\ȋ7k\guEH NdS l둭QDimGʮnݾi6r׮m9ϧ76}ΉoGGl3Ô˄\{,D WW   : J N!Z!z!%"'i)$Y1"+֨≩t;ՏYH6B ԑF$L cU9ٕYR\b饖]ayifl馚mqyy¹gBS.6Tf(52(N&袑R:)f*飕jZ)7jtw*vʷ*ʪ ]X)ߠk+ _뱾,*,JܴR{-V-↛Φ딀.dسʛ[/B<| #µye61fQ,qŔeẖ$2(br(Οެ=3>Ђ$$PIWL#4MGt` ,"7vm#[{=v_]6gm6i6&cV(Nx+7k|-y>8m8kÍ78"9OXb۝ǽ9s術~詛LZhJ9֢^;N_<'O3G[_=gOsއ_>OwfZ*{ c@) , x@Rpl% j `?(&| +P laYp+ eC7 mр6y"~L|(E(:1TX-bW(F0z1dэNy(8qv#f;Z| A Є>Bw2x~.DISҖ43MsӞ4C-QԦ>5SUծ~5c-Ut@*MgE׼ a |61[^')ɮҨU*mN;Ծjo6mq{.7nrN7ny{7߭oz7o˓~)aagS ZnWJM?Y7.r|!'yO-A|69]Nsߜ9΁s\E7ЍJo:ԟ.u=TwգhEktx%j ~YZio;v]n;|_ӽl73>e^`\{f3Oc#s>//?ϯoMWFTPvrB?LCQ` 6> BNFRV & ":jfRXʣ?#@TԂ~1: c:%xKJ`IC 36CJI$KK$LƤL$M֤M$NN$OO$P/ EաC>dDN>B@!4ljE^p Eܻ Hu!̠|KZ2ZJZneZ%\e[\%]\]e]%^%`%_`&a`&a*fa6&b.&d:&c>dF&e^d2!gr&Bv& !fSƒ8P&l\!S9JV.JY 6߱T Ok%B `DpJopp.qdq:'pJ gPVu^'vfvn'wvw~gBy"$(yQ:%B D2(HA1П4 qaNeSo΄JYI$JIFĂJxDH,(x^(fn(vP'z'QJi§|7Ґ  C BdtfJ.JZ6(Fqr6>)FNK* ,!g'h@A4CC&E!ݸMLJ6NjhZtJhG)NL$(oGP*Ln# l㊮ED&%8N .,QH*"E">q.trispI*檮*ҀD餦OTD[5_Y"XΩt)J@hB(Bi)>hFH+K.*4jKiS$8$gZlŗ~$I Y>,FNw1LjS Vj|'iXeԋNAR,˶˾,̶$! &'>ꋴh&bE,&.KiZC!v~-؆-RiƋG ؾ-ƭ+Gۦ0-:EB_2Ѣe4EFB`NFnvz.~.n鎮.nn.nn®nޮ. //o6/>o:oB/.SJ&:+ZBmB*Ġo*ooo/oί// o00?'0;pg0ops0p_p0Op 0 { p p 0 s0B ΌBڝ" 1'M:cg',Ul9rm!^g1ow1qBhm(_6AY#qbqMcd1 q !1"q"" ?2!C!+2%3r%;r$g$[2'c&{r#r(K(kr)(_r*w**+;ZG+v-DX/1003113T:-X.ޢ.^35c5g37o7W38ks8w883993;;3&6X~jHB+F!pl 14AA'4B/41=#QȴT)wkp֪*G4HCid/&q Ѿ T1n~+Y.KF5?+nj@ (@PcA9"u<*>SdRGRKuSCT_uU3QSVcuWg5W Q0s͈pQ4zO:S:[W_g:zz՚:zz:z:w:Ϻzz {z#{ψ}xQZw ;XN_k;{{o;;{X{{;{{;;{|'bK> ~7>?;~COW>K~Sw>{~揾>~꓾>~Ͼ>~4K%:I映ocg3CKW?Ogc??׿?߿?s?@PK+@ &HB >xp"ć"Xċ=n$ő RR%˕Z|L.qYS5jE֓QjՒ*u趢VbЂ2;lYgѦUm[oƕ;n]w+VJ}`ÅhقX5M1C\qT+!=tiӧQVukOªki5٪he&o[xq}'gSPϻkSBUX?|yѧWjῇ 0_&{";+ʮ.k蔂p Ț. 0- 7\A Q˒6XI]&gz(vT̞2Bk(C4\r&,I,0JҦI)I/tk@5lr\Ht,rH#9n1xSp+-2C)\- ÌTI) **NM lӭ8U[)TP#QQ-էT33zB<;!J%0Ѱ* ^5a]dEGmQj}Zjc qvZoTu5 mc2C2}7@  xW A' ֳljuBePm5V܎8de%kud_ږyeEY x7[蝎ubU JjȈԶ+gbUVd{b3vftٶymnn[dݟwrS7W|@U&^7@@AkN;t[XQW?yӡDt.=yoWLLXϸPoUq騃V ȫܵumf.INFou#E{S43f QEH ў( gvmTs/eʠ0H\gݰ%?l-e, Cq54mTQ4Hi=䡍#D%jHQt5,H6F(ΐUiԿ!bx@@N 9YOg:gڕfrG=)n#*U"! Hܨ9rby;jIMnt IQl<#aB $&5(fBd<6t\F/s L= S$&/wdS\3`Bs&5ibV6Np,7)tl:Nf:|Ӝ'?ä t uT)jQ4V@`h/QnTG=RT%%IMRT-eKS'q,{kaO TC5jQzT&KujSTFSjUzUf[jWUb:' 'vu]%0Jeruz%+GQ >`Ec YJֱd/[YnVg3 ZΊֳ5hO[ZԮV%kS [ֵlo[[Vos \ ׷5nCD hv=\յuf$J\WOѫwzez}}[_׾~\`# fO~/BV^DROV˕#5%6Q&Paw^S6NL1,W+KV8Vv|S fl"'=r+wya<,m;y)gó6H/M+*V*Ɓ,-fMMPKfp@OEBPS/img/audpol4.gif^GIF89alH>@=OUY!,lH H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗IP&͛8s´)F e94P6ɴӋ>b(ёV.ׯ5:ղY U,ZpZKTҫpU߿4J,Wxލ;qŋ B~[1˘wm,f=yiG3ΛkZV5mldV6mܹi-vmt^1ﺑE zoYgw~4W.Ͽ(h& 6F(Vhv ($h(,0(MTF7 D쨝$ACZTPLڈِB&%C;NI$)Y@Zj9PJzG`6Td f%B^Ico. Nr$C\9&Mn٣ni(@蠅6YP.z#N )\㡎>urh~䤣VY^ɩx^J릢Zf(:j}niAUz묺(-NizkRۭ y$>k.y:mn 糺zkn꾛-ɞZ ^ko +R\bnì2jP Wqû1"nz,3{mc|\oK/B\2պ,eC|4c*k/2&Ϋ*h{q{ޮ/o'7|GD/Wogw/oD{~~7$AtF_'~ٚg `@ 2ֻܰ@(ojB >! DN(L[+eh A 3P")h "2ؾV0\/(ʁX D2+P<_5Q%苣H:x̣> IBL"F:򑐌$'IJZ̤&7i;PKPKfp@OEBPS/img/bipqb1.gifw'GIF89a"R1cJJJJcRRRZZZckkksssssss{{{{{{{{{{{քƄ֌ތޔΔޜƜ֜ޜ֥֭ƭ֭ƭ֭ƵεƵεֵε޵ν޽޽!,"]H*\ȰÇ#JHŋ3jȱGBIɓ(S\ɲ˗0cʜI͛8sɳϟ@ JѣH*]ʴӧPJJիXjʵׯ`ÊٳhӪ]˶۷p͒tAn]v}Jw_x /O#^Ɛ*LʘwN̙ΠenMҨSNְ͚ M{ڨg6oкc@ȓ+_ҷGJ)G:;gLY }xC{Joؽ3wޜO.TP5G_h(}5u`K Xu v6AH'Ȓ |Ȥ"!/BH/G*"!\X4 *VL1R,M]hQ!XZdIe8؆2APdbIgdƊ!@. )RCo)!0ҋ}IӋtd_N6ŤX%[%thp\p*pX@* xg1~~c74.%5X7H"wƄ9ՈRqCZ03tkGۋv%^ &TD0GBɍ vVR#7iVJ:"Z¬\Т(q$5@CAPBB2ysA=M$5>hK,dI %,6XD6?RrcJ>яxJEq69 ˓\ ,q2ɑԁb'EUPRf ^DRxcFvR(%XEBM,ptfvS)jפPK'ԦӡA`T5,ą0@x(;$$Ey1 ^H`ڼٓ|K! =rbdqbO |N# NtD17Z2 Һ49A1It6`V+j*m/&3ωΰiͨF(Qb %Nq !Jk#愊Ql+Ge!skE4o1j]p4|ݪ7íjg#R k*LՓUlgKͭnw pKVS"e0=T 4W/Ęi;ͳ MIF8@1zoKfD##IRHvqPk&r<}jup1C`¿pP{͛+K&MSr.f c8)3qil̓@L"HNlAxS<N:eɠNM.X挖sePY4aUl=A6i̚W0 s6%xsdƌCD#=tƍ[hE770qڑlL5d7fI=Xv7)H6=5a6&k':)HTEԠd!Ԡ&|l=x{ִ-ߨt#_@4S!$-Nez^t]XdsUjWD`: ݒlD@?zJ{iI,7\ 'ɦ0*{C F'uM/Yu~gz5N[XϺַ{`N!) *BTͭt덒 @wO\`OvWvqԜϼ7_x. SCox9<c8 (>{B"$w* S=KP_= yJa~X?<|?v_P"3I U%R<&0P!=+_.TGX ~( 99 ~0as6qfz^~'kLR0OBU@s@y*20u381HuU<؃>ȃM$$NGGq &!k`0u{&aw5Hf(w'jkx'bm8'L|؇~}z;za`0I`޷[G6Xxxpxxm17ḃyPpXH|'@jPWpxdH$(1v Hq|Xv`KhWE`HExu8}UHxHphq@(wvy;hLhDPUݘx߈u}U :AH),L-W^PVyWU 0^U3D9xRyh}^^lbL:E1*W^\48,c"QJHǹdG|~̣)%U;qܮsL:.ck]㲘,ʨ ^쪅Wu'ȍ5Fȕ+2៞RpݫlVʦ̬Ա<4TT+,V 9v,ŌȌHKҜ߇j$֌F̷͂, :ȫޜ΍f zTuSϔ[+Ml݅+kE]-T*̯s{ɱi񺭛ۭl+1$1Om7:ϻ\BZF} }ʼ^] --L&ۛ9*ۼʽaňjZ$M+LC%śH `t׺уL4K J\eټӝ#f,6Ȱ}ڤْCZ\‹Ѭ' + :"]%}=<]<\:)i G02ݜ --< 9֍>ݭȅ1-Tp .ϻᑋսLJ{X$b( \Ǽ,a>(8ॺt%4}Z-J.ߨ5ʡͲo͜+:F"t[Pq,ٰ-УZOԃ=>ǭ~.wK4X۫ ЃUX.(3)YMٞ{ O ?j*O z=Zn/^|lMJg~\;+ʆmONo j-|Ī(q&`?됟NA˪[}\uV~7NڻE{뇍&޲y_% rN\{j-fdu.[-=lhD^ƞ,rߺ?"@TDPB>QD-^XC:E$$Ar ] &AjLxN5Y'ϛCe3(¢>QZŚU։-N1ȒTN\ ˜1P'RIu t&Rw6X0ت_FX ?Ydʕ-_ƜY3e"= c-]5+DJ+Tnܝsv{.^ٴq<*jG|E0VG>]괮Wvڗ֍޷y~{>z׊+>7z:kR0@]R00#0*+iBԓB4TÆ ,Cdp !zP?nD_=`q%:ѨBT brH##ƈ\H,P(d2K--I.$ @3#7ʗN;3O=O?4PA%P>ܪeQFRL$CA"JH7QM#T5c<Ï8eR̟r,V[kEVӬ@McROMU-4<֏?dzŒYo=+P5UkepbWJ&xW]y{+^02ނEhjvLe8pR\dEuNEt-^*dZ`=7ain8fH-7k Yclkgc7vKN<a39{R EXۗ} c]ۭWଵweff=k玉{ߍmnn; *ꁦnadAֻ)<aR4g h6yKq5η.zhvZt;_{eE v )E'~5$}YO]zߚK u2oƳ~|lu%=!흝[aGflt#CS1`RGJoh \,uGlԺ4# n ]FƝtqe*|Z^~ 4rh3 ý*u mm눢>Ѕ@QHoHJĠ X%FDB(bDQc-r=+v^QWm}#KsE^_>f )rhJgNjr*Rn|OG$QY GQ8!Xc-Tօkύ+lԪ6Ҏ.4I'WϋhQG$tKK]$R!rGQF&Wo]Wvp#]C,.B`=oK6'rO31vmXۡ5g͵"gfoB,;ީvJwo~gT߶-;a7Tj{mu[k7l6Z R7/}q_3I~<,&wSM.HlՁtqn=ߊ[UAڮNxk5$#ݍ5۶d=7f7gG{kiVg40[`Uօgz~K' )/0Aƽ؅K<3úlV閂JD#\+z6}drz1tX'$qp~},}oMF;Syt$g=c^zެw!"[#7v<.͟q{뭥ir"$S=K-hӠ ý l)2i!+; "ɱ;-!<%,ѻ 4D64=$ų@8ChC(;c? ELFG4@ԾbDEUE#j+>5촾 UL8]^ y`<7sLVFFlGGPFyDGzF{7}G~GjNOGU4H#u)GiHG:ϩz:Hc4K@H IjAx|A8t$IL++@:ĥDD$CXJ;tF#șlO{O@ \AdC\OLЉSGB$,Ěd Uܷ[HTH5pGtHeȖ[Qr$; .)H `xB`QJzTȀ5B ;x38!% '}R҄4EB7x.@ #0 ePX̷P"))т%@?E8)F9L`DUTEFa ƏX.-?UPō4;ژD'PѬ+ef+  @%K%P5L(AhDt)u5e)!b% !(XU,NU&AU(!Ђdd]B`րA^J11jk-lݖm-d-V >CRN:#UerWQWi!( pW|mrE}-C N3ݴ-B%X%!p[ձۋ{N XVE]Y!(YH԰ԕ[W*)BYmT{q5GBSɥ㼖L*3Q$e7!SJ:QHZz9)MR%͝<0+JϺ{;OĕD;u% ;  \]ᕵ[8%x5EUeuׅؕ٥ڭeNq^<%ޤ3ޫeUua-Tߴ^ގuUy ^.DE5-}Rm_;PKAK|'w'PKfp@OEBPS/img/emsyscreds3.gif#GIF87aAk{{s޵{1R޵{)){֜R)sRZ1ZR{)){΄1{1ZތRZƵ{ZR1)1΄RZ΄{ZΜ111)ZZZ΄1c1k)11ccքcc99Bc֌ֽc99ޔ99c9ccc9c֔9ޔ9{JRZJkskRZJsΔkƔZJRΔ経R{kRcRsccƵRs9s{ZJR{sZk9ccޔ99k猭ksƽcks{c99999cc9cc9kέ{Όs{Rνk{Μs1)RZΜR)1k)s1R{k)ZZR1)RkJ))ZR)R)1Rs{k))9֜{RJ{J{Bk9s9sZ9JJZBBR!{BJsR1kƄsR))))9B!R)1BRR1k!Z֔k{cBֽ))1s焄kRRֵcޥƥJ{ֵ9B99ZsB9sZB9c9{ƥ{9ΥƜcc9ƭ{{99{B9Μc,A H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\"0cʜI͛8sɳϟ@ JѣH*]ʔ{4JիXjʵ+V ؉e ӨC`cˮ]x˷߿TΝyV*NnƓ\#KL'N ,83b6go|yE=ٳ۸sͻ Nȓ+_μk^)@ w}O^b'Jξ˟O`F-º۵v[~bu`wفNF(VHtw]vzVhڂPς,m@=YyKtBcbYLhmNOfPR)e2M%LYgWzZbkIffYbn٦Yo٧syI|ꧢ湨ZKITZ 5Zi;oNT넗 p@:р t!xHHLB(`a/#H<"vpH2h E h, `A&0&,"5@˜V2tH (7A,He*w ld n4 6;BD( H:28t@%+P0&s(IjZ3z3e1` ܠ8AN\Xypd>1QL@Ӓ=f2y~<6{1 7N#16d X34ɼNHD(<"z@;`.>Җt[@12Nj,4 3 N,&4wHⰐ09R4h_JժZU@#Li Y,4KB e3h"ǩVm B3IӨ9&'zվ;/z Y 'D`h0 Z; d!YЌ-nq \"0iu Hlg[٦uȭnw= l+erb΍t ]uջow?ϼ.9Wv /*x`^^x&߁#am߇7^xv:AL! Tt򇒤q*B@ VuE9 R96d;xqv|]OQ6*Vqx撼Ʉ&S;Dd{ [%[ R0acFyH"oENkFl,øDr&*4.wJٗr3Ll7 lsoƄ4guSV? Yx(-fا~p7V== x‡_}x է('^|]zLd.^)Ktc8~^|Is6aGxbVv zʳ}0 6w]ۇz_|j6`Gyhx{Gu怟{q(_8sq' 2_<~(|#Xs7q<À/8~wvʕ=FR56r;ngmqG^6ggsX 8pJsGhVhH^dglqox>vMg?$Vgc/ƅfu`sJ}tvƇT`s)Cfe>tK]xyx8r].'LHXsvnsl艶FQ |F`c(uFXu=&w$I{7|ccB&{WINyjCO84cܸOVw֊OIh~#]^܈-8tfiGwX&H<x bh ٌ#{ޅ%U˳&r GxI{ BI(ڗl9jIHItCsa~U=RI>NBUIJL)>yOyb d|SY=bY>!TcٖnWlr9 פ#jybd(vI<|)y[⣀|C`Pa wXzI2)ITW=W_a$L8^I=) wzɈ}i`IÉ[)=urfuy6k&}fבhTçi7kv(Ia\kXkkzcbf9GK 7Vjf xI惈kiidylSe?iŨjtdziiyUtrCWx oGpnN灖oVu-7mɈP78shn&wvQguqFs&Dj>Ƣ_wC_ a3p(|C<< 7{>vsugv(n~br&;EڶtcAW[=玈$HGw]׷)~7{֦E W:Fu LPp@*7($ 7Dk|pU4SJ(y: # ~Ȉgz0R*1XA^y䇫 P }Z ?Tgb2h%XHjxu/YLJC?lj) 6`˨|}/{Jm'k{ ' q Eadcj?JrI{jG[$[˸$':h^HEdz(:Ѓl/y*Pz@Qxp>TW{x&ixpFs)<9kqkgŒ77i yC믥f蓷JHB戔}J ۓVHDtyڣTՕ'jBK=Ms{țʻۼ;[{؛ڻ۽S{蛾껾۾;[{ۿ<\| <\|5c@ lcPa3<53bP3i`*|4MPD'Pð5MpH\3M  _ O iCWy3_ր6%؄:]؈؊،؎ْؐ=ٖ=83R0 :}ٞ63Kǟ]>E3E|I^ļ,<3LX6\^`b>d^f~6S P4h]=%\@4 ;?m8]7l\?ZN%e}Wann-o e_ "?$_&(]3,/;.4.44/8 #|ID>_3H\lЍ\Š2%z<ꥌr$31ڲ\睾 umSD\n-+">:S~ l>uZN:)FO3/k}]T m3<*,#0]J/ݑlQ`n|KL=Dy@t m)o/0Cϒ\%lJL,]`?o37cƃvIS'!\l@@S<QD-^ĘQF=~RȑOHDRJ"ǐAɈP(iRA*[TrfPEET)HK>hSU^ŚuV]UXcÖEVYmݾE\2ś]}bWઁ kb*7Lqdʕ/NfΝ-bzhҚAF}tjnWul^gvnQw‰6~\y=7w#t閩W~9۽o{ 6>zzzٷ?>]{׷:p$@Rp|p B22;TCqL$D[RqžZtqFjqqǶz# ,kH";r9#kI(rJ̭J+ҷ.6.3L 5dM7߄3N9N;3O=O?D3PA%PCE4QEeQG3RI'RK/G*s頤^$R4NK ;XV18:5#RsWVMU6'y裂$C$ZcY|^aB&86lX!7$zIe(#=EV3hwrkm>jE&0j&6[mU^p t :} a^ xwW 8C iu* SۭU 68ݖ_cxabٌ>5v℟p v2"vz ~IW6wښ?^Kf@vy"2-b+  / )ۧE3uv 8 VlxƘFkީf@dT]NOıFs_[sZ^u֜4xixAwcGGHvћUeBj 9vq#^/>?҃ +ħ꦳,8R@5&[FV:)KtAqp. 'B0q& OP[.4 S%CpS6 Q>%QF< D1PN%PMVäpK^<QGfd F!Rnl#$Ga,vD"Lz G +"H0H$hȞQJ$CIq*T'?)JP'K9U.zxPɩSrCSby\>e刂av9慒 eJy^D4K$^$7 $dʜDg:չNK}ӝg<9OzӞg>O~ӟh@:PԠEhBP6ԡD 0Q'TԢhF5QvԣiHE:RԤ'EiJURԥ/iLez$Ԧ7iNuSԧ?jP:TըGEjRT6թOjT:UVժWjVUv kX:VYպVhj\:WծwjZ$,|k`;XְQJXld%;ٸ26%-c)YvֳթeQٿִEmj*ړv,Umle;[Uww{wo^70x(| |7@򗗲? @AV^`7yS}e?{=ZV @z ŗgkwR@߉V?~zU@տ~'?7׫$4@Td\@C $4DT\A:ߚ@A !$"4#D$TB t,&t)B%,-./@"3D4T5dC/789|C2@:<=C;@d B4CDDTEdFtGHIJKLMNOPLD R4SDTTUdVtWXYZ[\]^_`L b4cDdTedftghijklmnopLF r4sDtTudvtwxyz{|}~ȀLǀ;PKDK##PKfp@OEBPS/img/audpol2.gif}GIF89aQ!!";MNJMaOUYTTTe2yyu|}}~~ՂփӅՇfF،ٔݔٙwWjܟҠӤӨԪ֮ձ׶ڽeŸ2e!, i*\ȰÇ#JHQa3jȱǏ CIRc(S\ɲ˗0cʜI͛,3 Xϟ@ JѣH*]ԧΝ2IJիXjʵׯ`ÊKٳhӪ]˶۷pʝK.h˷߿ LÈ+^̸ǐ#KL˘3k޼SCMӨS^ͺװc˞M۸Cͻwݾ N\57|&ȣKNҏcߞZ;y{yPLJ_ϾW/{ٗ ݾxhvoz(VZ҆ahh Zy>_,zh4i j(((DcdJ&c>Xft^6));Fy")Zp" (+"r$Oil:昁6(xtvrg{y˟9yh"X܊8Iz9-`Ji$J(1 ꍢjlwh)s&0.Jk&-ji&}.+P(e&׬yR+ n xmOg)Fnvn}R찲^|[U/f,񦾎 yj | [nɣfŦL еܦ*#B\Mǥ0L1L4 IBr~L" F:t$ dj&7Nz4$CIJܕ('UDcP/D D . Md2 0ILA<&2Ie:X'&F(0)D#d8Ir&Ӝt&:9Hu.D$M?ءn@ 2 @E/,@4PB,4cC4jOz B):I OҖ1<">`. PǑ'.R:Քte ATpQt` kX" gmYԶ՘,)dErҨo5'^ (`+D#_0~ d[8ٝT6KCy-[v^5ӕL`0X$Lᰉ]xXZV-@֚۴Y{npK.Դ@Vj &vUJ!Avxk"D_}z g6čqqV].}}KfвLk3k**>Bn 7t~pޯ /ޛ*w/sU|v]Lcq6Zd5x7.+Q7 ohC .@0W27]md+ c.Gh.f7Y!oee SW hXC`'(0H )"0@(B-w2~{[H{Y򝳦Of= `|ifv,A01| H RЂV%vkJX^6.oKL累R;ԝx|86s4*(HPvpH"+XŪcO=u`>jE85!ݝtߦ:(mR"MP 6` 8 `6 "np:<%wV%/ ԓ)9mXR -uKR|@on93ҡ&5aC`ύNu}W:TEZ>zЃ-$~pNww6.i?֬ն_ч<l` #.5|i1mGc|'OâWOsy/!/yʟ>}@_OL}kiOzO]6g%'_Go?=RR?9E>_WނOj'.T? }e?ko){d[vb'>}RWw UѐZ'vdgvh7eXe6_JTZ (v[ Xji:}f}ϤyDu.^偒Fi%R~$X`:@H7sD؂Ww~Vb0b786!}:3<Ć!y^I(PAeV Y N̑t}G]#/ׅF0& h8cgVmWfoI89vxhykklE|7m#xHr8H8}vt؋G1zuH%ȆyT( '%#GhƎ"Gޕw{d~xh؈'w|w|׏uא9YqwWɏ"Pmxw')$ YԒ'{W~Ƨ>YqUhH@nDHW}H}&5W*uSWŇ$VfXǕRTy#`5f)BvY~Z9+BȖG}G|XE摗Dzz՗-7F)zEyfe6_&lHl W=xu*(GMX\Pbl+VWV[Ӕ(pi*dhg聣y,O(WofWBɂIć~by_ٝNԖ\W_ XBv8k؟Yx W8m^x$Z𘁝Ɋk[yI.:ͦJ>vWP 'jy)8JxH+>h%jIKY)99:=yO9ySJ<ɠb~dxP /饬lڦwՉriv:Z駋*Щ:Zzڪ:Z ګZזSYRڬڬ:zzںzʭZz:ޚҺ ʯ* Jn! ۰JʔЮ[ jza ˮ+ۧ~B!:ɱ36{He8ʲ겛* k 5M˴fO@[ +*W2uV[Xt)GS;M˶_qZ)-r{tc۞i3XIl[VL P[3[븑˸QK{z+E  }k닁k˛u붙{o KۻƛJ`293{ں+i# 2۸ [˻ {:{6ھԫ ڱ[eeܫ+ދ\ *f zX?r"$<¸ +k0:ۡ# M yJ&‰۹&|I8<;*jST :v+[\ƟűJoLYXܣpjP` P  P ` Ƞ ޙވ}LiڅG|J N ~||4 >~ ]x1]gN!>&GcCH> nwJ J.^"^F¼\^`nF/VNP{:^<K~A~ioG.wݧUMO>HyX.~σg܇΅pton| 8ݗx ЎeRVN)}H ѓd.Tؾ9봮 ؗ HԁH] qJh$(ԖGG.qtYYR ~wG=-(c~.L_iGWk`;Ǎ)R|ŅblQh]YϨzLd&:CQ&.,ըy0۟Sn*:/d@_L5:coYW\m!zߍ*ZqumO>Me_)+ZJG~fhV纈͡,]OQ>^׵o钯j/(vBo?WJogO⿿Ѧ㨏Vp_ѯY|?~mُYg]ߧO?IM9n?uot M@D`h 2dD-^ĘQF=~&% )S\pKIęSNoĸi,ZlLX1cƐ)@1 ^""(Q"ıEVZ!%(@%K0FϽ}%vPF*e2#^jV*Y :9ѤCZԂ X9ÈZ.z4ҦO3?V7M:-^lmwc_7 Ol1Ǿ ϗ:33PA0B RMhÐdmBY-C+(D0xV h+F+AF>2HTJj#dpH!찵;8ŎsL- > EB mQ;;vA(߄S'"{YnY/%Ok8O9+2- ,aQJ,!x,MR33ͰT5W;s\KPQ_uD W]sWXqT U]`hX%JP Y|6[P5Io[e%[fD,G%]w5xߕoޏ5t[P_` ZZE]fC}a"_imMTb7ލb8=I) u$eWfe_9fgfo9gwg:h&hF:it/ꞲbVkǖsjɮ쉼F8j ц;vX|1Vn:dh gkԘ"rΈJב-uKa2MF d'RHճ'U;6J6QJށ A p!y Ƥ+TݡJIZy2vEMs`2Vʹys{$76噓^Փ\5Q$-O 57l#KӠhJtJ\hDi6_@;PK?v|PKfp@OEBPS/img/jisec033.gifGIF89aL٢勋À=>=þccc~~~mmm III⥦zzz666454YXYUUU-.-iii)*)@@@FFF%%%qqq9:9  111686vvv!!!쩩]]]MNNQRQjmj/1/󭭭|||⼼oqoܝﴹrur蕙y}yVXVuyuefe]`]242Y\Y>@>GGG464;<;SSSKMK+++BBBMON###'('||ij565???$$$wxw `a`DDDsss++,,,,󽽽WXW///OPO333353777߄797 ___DCD555rsstst[[[[]\\[[KKKLKL?A?ghh0//!,L H*\ȰÇ#JHŋ3jȱǏ CIR\ɲ˗0cʜI͛8sɓ@"Dٳў?*]JPJJիXjʵׯ`Ê}D@RhE:˶-زgRݻx˷߿ LÈm`vcuK|qǘ5ϠCMӨS^ͺל 6`̸#nͻwkٴNqȓ+_μygo>T밡 }qËOvݻ/>\߾-;i߀hvހ`r2VhQkruh" !'\阣24>*zbrruYav,pC;f+6~sq@CÖ; :pt0gt@)^bL)t +xM0N˅3$Y @ @0p0R"h/* HV(61c] #`"#|PtA0Q pxxpg?v=t @ "# +0DaC=RrC7Rnʩ\~ ZAq`2@BXp/-H @ -h  %Y A(tP2@8pA aC0䦹 ǝ`@i˅mOaW)$-Xp:acuƖi\C Vl&: \} hp3"pPLS,ki"n pV\J?eJ%nL]X~*A.Й~& BE o,@ al%|mp4`P(\%h rtԞORPג\਌gKLHCg4VM(@} <bg"|*gWѨӞeGs)%aH`'t\a N'(v0+2,cɃʶ,A9lK< m(-PYZVNڬI0%-p[$=`;κ%M-z xKEo>^˟$&.G `2.8L{ ^Dj{ݖ 6{ GLġ[p[Fx#(lWr'`BdnkduCx+ȃ?boK (:^j3[6vrs*dKh &QN͔kcb#CP5¶ i@hNi\e"ld;ӤgA{mn/!SrY), =eHz' IiC_yQ4l`nI(  Z9^hZ-C"~9ҏ# 9"rvHb}-l{>vEewX X9Ҷ}_38F>cO<۳'BnnBw}8y&g.0 ʙf0up)~z8{D\ Ьh   ]8Fd!N am!UIDڃ+=f"' @I7b< $`J1'KT@/2rP N؄/fW)̍0<$^$nV 6`*@``R6 ]W?fHne$=}j+F j*Y63; m/D#.4NRz   u\N>nB Y VA2txtkF ѶO0Ѡ F| .a F|q*PZST7ZIgP p =gqs)=xg 1H. 0G<@'-bQR8 :&oK ` 1qviikT䠁z!0߀{vw7 P gP8wH&` IA28հgNj9 . pJZ] 0) %uͰg5q0 z2`M sJ`FPxp>?!+戎Pi`c`0<H@`8#@0xL[O+H Uq)$oR@pyBNHHZ膥wwJEO0~Edэ2s9 p: (Q9 #@9@2 06Єhpj08&B}&}$A EpPVfR(]W2 ?0եŀ+Z 8 r>iiЙ4C B `3 lI* ɀ{I}A!,aN . yXAN @ˀ  R]<9ީ *pv@8lIX09!a5e{'"! th1`8QH;}!э$@`? P,@75# B %%g7p7P&{kJᗖf!qv,r! %֍`[}%k@/ <@jkpd +- `c1P <oJo D@KZjјp({K*э3-n0i#: )**`ڄqŤᤂ(qŕL * a0arΪL tYZr ;zD NqP(ف@1N֗Z5U5wȯaj Ȑ   ["Кf ۰ E +-QzH Ѡ x+%#%ZG C;BK0pz F ʐz%@8`%F1Q&.8 ng7p1@0 [a0)&p{{$)? 'P *`'C54'0K`B;Pw" &ۻ;[ Ȑ5opq[,0+a s:5}+\ !! EН@W  p " `_ d1 0pH A& i"[&|(*,.)(м5&,! .)4Vd , .07` ? E` f0M!]2`:ː#)0MxČAȦAqG ȊȌȎȐɒ<Ɍ6}[!.)-!DjF@B=<6#(pliF|  @E,`;P;W p ԵA5= @ &. ? x uMhXMq`t[Mْ=ٔ]ٖ}ٜ٘ٚ]* K l 0 =6@|[6P FPf IF-0 F@1ܱ  5ЄF @ vЄۻM!5 ' ؗ ;YhC@+``~I~j o*q  J*Ѱ*צ !M>,%n5߾A61\ ;Ja䢄0CN3+/o@QP^N/:>F,pЩ- h| ._ @,|K@7>QE`2}`{xp@M@ Px&;I8q? p=@k) Jrx xP rJ@=$D^<㐿p߾] ZTȰW}Nx9Dp˲* 5.MRN&~\ 0}MЩŷN-R#@^_!/o..N`Ѱ `84o":N )0s B???&p*x_ B@XC@΄_$p f0so,iAw Z<xT ީȠaWE Ep`̱K< J%#$D   phg `'pU@( ? .dCPѢE JlG!E$Yr*UpdΔyC9u有 .`UT,TQ&ۀ"n],ԅ 4hٿ\O 87ĩy囷v a Ӽb*? H \Y"Ŝ4gСE&],>5}L,(hN)nٲbj +kЊ H$$|9> :R00opW,"%Spp'\0&' 20Ɉp ꯸~\L#~( CGk1 "eP'a"Fq\X@LqLL4τfsHL$sp!#6)\K@i)dR ~@O -"΋VSYgX< !蟌PG="<7xA&r~HzH-(/3Z "9A3'+*t $c а,)8*ƵT@LEɧ 0D'Ǻ&#^8 %-.ɧbi@m014wf [svh@Dd(\NsszE{9)UU' * .# ` v^˷M!K)K'xk6zjuveLbxE,fQ[bE0r8˅/?@, (*J^s9QS'r(H~a5ÃS -?PĐAPF !S!$(A OF*bŸ%ч zPV,H&Sdf3L{+jOF #U7 Ђ0BJ*@C0xNs@! Y[n\c9@ *k2hHDN!@nd` !$T &I09&! ?0a0L :j\4h XP9!XbLФiMmzS@ј4 ^`8G(r@@ $pW'Co)h**4Hc}} 6`"J8ƔLf2Ia {X&VkPX.3 fȱR`"RH  ;pA*hAmMp[ܚ`/l e-[)&6Iuhⴇm0o(W~TL7e !wܭL`"3Q@eo{^Wo}+_]8eop'S$^pRD]JxV!0xl nErL"pfо&r. Sr ?V!T WHR_Kߔa9j.2MrsUiL* y$070 iJ(\h2hVl\` Kh> }h|,)h$AuNὴUk<q$ f}KLr9!}؇L A_֪vu8`+ N' V0B pkaشN1я[S !0P En!@@%&z-;@]R%'xA@Gpa5xf0*~ ,W؀\*V8\pHAeR h@рk0rfaZ/C jLG9v,U7 It a`?*c~@=Rvc QaXƼ@8 L@X\@HEO"CJ:K,iM_]t`xȘcut@: u ݉tDԴMH0<(Ɇ҅_Ї `z_ȁ)Q۴1%1cpu(&Hh0[ oQR.̨"< 8 @s(8!(K~@S5" mRS?-:cЛyPG ,iP( L@DL;II5/7hPC 8HrЄf,wU"Uxs{ $6Ca:r82ք[0݉f323c&qFPOyxӁPe`W_e`/ TEKPw(5!yɴƀwkhHkCbi _PZ8ξ9ajHP jcq8J `Ȁ±P8xCha8cmf֏x]o!y1mXԵ&iHGd(RRۤ;bF`">Ђ@AGh -QMH--RoRd{o򖊮>o3 apg ޘoh $D=fkx/x%F"j$ {XAP59%؞+PC'('/0hyh5os+jme9ւpn~ "`\P*-meȠ!XP !׉1Lr99Z>8Ȩ_cZG_-ɀbH]_d4u8h_Yd>tF\y x  4 f G#a O JN`8:g'^I*w~wxo@\?xOxGx %4c6t߲D s (> ؁dL< `FhyyH)d4uX6Wj0$슷2즳QVwP[( {ǨȈ{{X|{c?|O|G|homaQ(qlLzk zx0Aƪ R`XH-P @$g6LLST %w[q_nzÈ0j8< :#jY'@0Xz~`0鯆Gj@jjZ\e,h „ 2lPXD7rhW`T&@4ʊ B78##P 2"ҤJ h"ƧRRjUp&ۀ p,iԦFB 6Jށ `_| păXNܻH;QbrDL @v)V XīgӮ׺waQksT2 iЁlUV A:$@/EDo}ӌAo*.Fl5Xm"Zp;N4N è 00`p=_?6`,4AJs;4]xb*J)DZo$oUZy%9}FE9`14G& :! 2pT|Ru%VR'k3 8t(?S"&; !)2|D S7H*Z=t*/tk:1 ?D$#Tm(M[Z{BZthZUSz{SkѴ>Ĥ 8 $ ʰO*CO$C) CAc ?4O: nڢ{rGb2֚ |(˼R;_3 @͎CLc?+0@Bf,<?A0cI=d?&`Q 8C?a;rˁ lT %T.VEDD*HN{r@7$?|0G0|LZ ?,#?@pC0;+E̱ +r'27L-*߀>ق0CEc&h.b 2#l9ͦU2EȀ<]EA <+?t8 TAl l  Rf8DAH@C~DROgkطq2$8fF ` <.a )AFHå]@BSR"2%0"+$ RDGT>WPa?|Q!AZp#G\3V3y)~l'/c:+QX`F aq }8 dp"` 2 `E9.|]PPsxC~Z&_PhA (_0Y T 0`p|N3 `T*8oer],;wMbgVz-xVi 3N؆'bq aBIAI#W|H !`P+[] q#L x:*; )0$uHB:V jAPXδ^EX+*?.PvI @HABw`htI H4 hw(,g+\P6~$` Z51\! ƈK|d!+Є:I tsO8PnN@#3$ ix`D9@̌0B iN 0"Xba%3y@4ݷ٪|]ttHc+pH`. #"A: Tc5/:PX˺ȁ0pY9XW&^hJ%WTw@DP0{{PA(`تĪ@F{:f J6n8Bd4 1@XcH1@VXj7RA$ 0E}H`\@9Mm6J͑:w_^`!  |SF@؈/N0yo@ TYKST6nS\0)EG\BꊗoƟCF,D@U$=X` e|@@b! [$:2uS$"7i(SK82   &a T x@ J _|?O!rf8a>;`"Udo%ϊ.de8yZ FPPl@8}Qll$ pExB: B\Jy; \ *̏ !!&!6,ۣ `*e1 q|NԠ4 !!a]:M!ޟ!q E( p!v2""&".a:,e %ba]Ul1("))"**"+b+ZG>b&nDMb-%vbU(2,#363>#4F4N#5V5Zc8`8C0J $"}#! #GF9 :m|`Y8L)(-Z A#Db;;&bC;N  Ň)C*8@NU APC;Ѐ:?|G0.$NN$OO$PeOv lb:F:d-!E<Ĥ>LIZI C>;@>$B4H6C1 @d@@dJ?^?%_`Op> c6c>&dFdN&eVeJ&0QF/feU$ D*CH<)e-d B__`Ah D`B@C:8?< t@81@2+ \2lpqogB'zz'{{'|Ƨ{fBdgzfif$f8 ^&fAhH A1T8zh^hOŁV(() 쇜h!&g~*XSgsf&:+L6N1( HDB2id(h?,?)i;S*&.*6:j)0ibAiRS\Xil>0L$C0hB 8_*4 h: +&.+6>볲%Nf"Ŕ44+RS@C(XB>|'HDd:(?X@=T 'kΫV빨@PfR~&D 2haSAvY; X0H&,H4`Ÿ"b,lʮd&vl dXT09bAŇ A@A@ HjH `>$?@@2®@t/<` H٪6H­V>IŒU  *Y8BG,@8l_inEt=4AZ~Ran#Y |&d_p/X2 X|,D@*S&@@р>.UD.$X0\ CXaEF@Ԁ0F(\AYYԺlD G F80J*Q(e ,+dE |,0h=( T0BA:3`4 #^kh pHp;FW@b@B=a|@>rC#(Tl.?@0(Au @ǒ@*%@+0E0Ltߓ AsU],ct@va2%_2&g&[r&2((2)+)2**kdqh.=1:sCl.Eˡ)DB3ߓ/< $g 1"'2,7FW!!v93::3;;3E5榵Z5[[5\ǵ\Z"]5^5^{oy3UI=)o*ù@C.X0P+E,=H@uav@H`/b3Wwup@@H&3Ӱa*/m׶m6nn6oop7q7__O ( =P t0 H_ux,AV T&7@s#(-#s?5㴪MF;tѿlN N=PERM5 QtR8+*RVՌ2W2ؕ^}`bGEeZuu/u6=EoZlyv[}Z63meUtw]ƭ\uw0umn^|w^97}m`|y8man*FX2"W <EM>!xcv1~9s4nyf}蠅袍.Z gFꪭ묵κ6f6G{nXnv`w_%\r(qJAf(%qEM ̉]e]9€u݉_6'I?_yy P9V++QTaIXB*p,ӏ91 iX!FlC, 7PD#ITD'2+OPm "Ul`aX'R@#1ee-XG;yG, EC   HG>$&(V2&I_dF(*II$X1! @K[B@XˈEZĀ/YW2%48vb Ŕr/L9RE{2GMs07Nl3) d,AFw8*eZP)07PjQ(mCcըMzy*%Jd aAy#۷iWFx~d 08ܠ^  4x1'`F?1Gqo p \` &lBR!4!@h \@$\J0dM 0pAV` 1B Ϣ!``Lp!c"@=RaW@ Ai . V!T |a#;#m$$@ o%[cacnց4t%/R/ ^AD f:`^k r=nk@ L&z`q@V!2AF.:3m@f|iT-p +H&%@  %s4 ! 0F4O:"@mj4d6" Jp-aFD| =>2,# ցa!V` S@`*bI" 2`Or*7p3#XS m:V8Hb^bVa RN2tC{J!!N4EWtw rt \8 Z >Ls2#V@b$` %J@0\lKRt60R{!)!; R@tJ 5HA!8₳ H!6FC Q#uQA6` S7Sn3; Kέ2L[S 8a N綡LA. ApP@ATj@#& VsM@A!~&VT@_aE Hr^:_ #@A ` B :Db%Z JZ,[i2Z 3]x" ^ %r m*5C L 8] <X s D,$lǶ4!vnm3 joo ; ii_v@0j kNki0 Fe :uay_W |a+vpW N 0wh6yu-tzV®`n·AivWWWx)lvj@ iwwX9X@CisL`^8~Xg6jr„ur `Ar`؈E})'aWNT0Jט؍XbX؏ϩb8W'u8".3Y7;ٓ?99b8+B[ٕ_cYg`B)'X=`AO7X7` ٙYٚ9io'XyYǙٜYԐ B7`A!@Y#pAZڡz@|{$7;ڣ?CZGZ*H/).!9v_A8`l!t@lڨZک9R;EnᩳZګ: p @ YBf@d6@2iL* zz![۱;Ԇ ؠL#"[7;۳?C[ޡVVB !T`΁X@=|L ,Ā uZ3G۹;'@1[QPsXq쒮4dA @.` [' ܱ#  9R|er :A(0 ؽO V>}! .L8||۪Njȏ#L~3i+ ~!!8@>,Ȕ[O|>6@d ~Ja@ ۿu`{" ɵȅ >ԯɋ}#B ~d@~ hu(P 4 Z[D@A``ar !`@ \]ѱ٧ڱҿ{{/= X`.%APTa!ԛRؒ!A]KNTX n0@  xؑV!=8C;ڭ77'њG-2@2R:# b8fs @ j ?^ ~^>ݳ{ <E  J߱ bGCfE^~;׾> @ ,@>ξjx@ 6 @xI-[EGa ?b ( T`A@[:|Xp˚Prk-(T*z|(I~<2%:l -3Ν<{ 4С;A/_-Za+ GO ѢG;vg9`t #GA`5\r !Мȱ +[9bą.ѤG@%0 Q[ق@+*Ao%P (HH Jz"@&2wySQPAT$RK/y6SM-`RL9TTYV\yXdZl\}e^z`iAa)Ƙc2:Muh I$i6j[B%t7$Yn@9K7HSR `$@=?B. :(=#8r\*'4@pqQZ70ȁ䪬oc^=sb/  AAP{$8^~ɱB WЂ =p{c #D>Kqc}Ǽx^A fSbtV=&N2A` #+xU^aBB, 1ah]`6"/P>!0c-@ BW|(4xȖ =|g!y' K3 0` 0q `<C}D qBVP r lP o @*'{Xh8첀UhuqfINh6G * + ] &`}0Et 3İ` Ku`7p2`GI{MȅeWB8(`W]xIkVA^  'P N@n` 59/?Y3@ t0h08HBFƀhǍ!! # ' <䀆 : *P850wp @ (S'@+x1!Ihj_y+EH x  (_``)`D bP  ~! ar*9. YxlTgxq^6 _ȕ: 2  ԰ @G#)   a@pwzhY#IYxj#9 @ 9 0 6@) `rM? -> !#yqtdAɞ )Iii+'*`   p0b 04P9 )  X۰^Jx#t`1B|𣌓pIKMʤOQ S*UJWjY[]y6 .+q,`,)-y#^~Y 8ƙ!I 1& D !TEꪯ *Jjʫj YcbFR,qvAv#Wozo@"yjZ#%4l)  .@ PPaP(}]hV T@ []F2`  +Kk۰ s9 yZZRero@  ,l`0 $?` 00 PZ 6` t pАˉACBekgik˶mo[C !9+zbfR);k+kk5`w2F 8k1C< E p/@ W:@ JO=Xd∰!kf  Ka|ظQ#u )%[۲a 0[D ){U@CL0>4c{L˿뿷ۻ['QKq|Z0[r){$ `KKdP2 € #APJCF!;yE90!!Z{[R ,k;cukA<>a 6 m49KD' #E P VKq;Luli?\3ALWv"Gk+%.խJHj@Q BW Kp/@`e7``p [0$6Lw,˳|y*EQpi׷ Ĭw {DȻSSzY6PD(%A*T`&K˴ ܿL|̜jIbK[M||2Zˌ:pJpL k!m0P@ AU` l' ĸ<ˊw'0>UA1}o4Hpx n x yj! n`sP0Ip|`31ʲAG?[P!3P0 ?! #-%#` p#0Aa0aj;#<@7ap(w25YpP83Jz|`7QBz NͶ 1qspX::1:p0R@ :0@ = C0a0opq 2*`ղ= c-o `V  0"P*,- ӽȋ܅vԍ a)fPt5e$AnnTb&[Pf QC P105s^k*ak {c P 0 D 0hM0`MP zU` p ` 6` b`` ;PB `i0@:0 i0  =5`Smǭ^NȀbj [_S &p:Tp> r[ a& t @Pp e0H-Ll O< 'p2Q Pd@ ?0`]p |P o*FP?pH 00ZP͠  R?#` M# PBp` o  % W 04o;Do.q=I-u?*Nz{  pT=˰9cp>yN 0Pkk 2Y9а##: M& &@6} l0 ~t1X$MR3ݻ47` `CV4@f$ pqUjʑ6DPe͞EVZmݾ7킋4բE,^@_? xd-ڊ8qHcI<ȑƉ,1)|>@0x9r$VÅ /7X͉qP\pN({!acBb" 0I$XJD|#AG@"&Ck 29p0 ,RRzP bCf pHr@N1!PfFH.@/x@TEG\j eRaCp2*XT4"&4煌R0M* 2N;4.K/L0 CL1L2,L3<M4LCM5p 6h 76t-^TSO5E+-`B+ DLD2;pbd~>2n  $@,AfԌb0 "p HiPxAxOFB, A| "Er0~GRDDR[״mnm7B#uhfKՍYm }`R@@8V*:v^Q<<-.HFZvb[Szp>@!%(arPf'Ä{s/ ".!` fm.C!hc }W II 'G`qA/< yMg: 3́Gr?)MPM+5EYQYTh&5KMSfTN> / ܠVae`(@Q H؇ L`q,14 `-|q P0D&n(B]խ`DI70ȇ7*"#w$JSdуW<"0$Scl@%`x${"L a7Lϸ04 DTJ"0t@!b}d#  J*>XBdIA8- *( h Kw:nzf<̝洧Ns *@P&X%g҄SOGFS4B=PRST5HmMR^c2EMS8TծgJhXCQ0!+١B8 QPW@*,!(X2 T([R @XtjMZֵֶ͚&쌚b]uݴ WéAӃdMY)6)\ȢŮZj~ְ@DsFx׼EygZֽo|YNSn~쉛*83Urvp aז[Bw0o0! '\W^(#+$6pGxp7/x9ۧWڠq*q q T-yE0Ls;W6oB.d$ {( V;?SegZ% t7Ozԥ>uWW:1;my^ G:0 x&7gs76ta_hA>z+))!2$?yW|5yw==u JN[ 繸6r! ^+<`o@]pς W|K{bE8״}w?~]JB] @%׳=r[9v?RXdVs)(WHh{>@1{< gC !%l?z *!uHm06H Ѐ=;X+ Q9>`HXUP`A8OX(XEZ4C[t<\]$H4E:,=667ǪJ06rPQ@zhFuP()|HzhlyF8?2`0oЇcȀZ(~ ̦G2c4;_LOAIB7 ZxO xdhuK`@0xr  8_x]p<<2, J AR`ãJJF^KHX _R Wp˴̘7P n1 0TH>9ܧKM*hKSMb 8sHj$Ncpm8l<~ݴ7+tM|ML \ی`CŔ4NNNʀs8*s( 8C$$X9sZ4[@KVe4LYXQd?]e>N&i.YNГ-TezcffeNpn3EbdsnoQqfcVEy~3uVev.`wfxfTn}p(pgBgvh2hd_vNh\hؕKf56FVfvi#隶i'ߒ_s蟆vo&FVfv!Huꪶ꫾ ]r&e갆o'x%Pfv뷆븖빞klFnk{(v]e.oV vdžȖɦʦfd[6>ldv׆ؖ٦ڎihFm%.1NhHhc&n6|2m~VCtgk>n Ķ[g\oxf&NodYqMhnF~&oojv|N poipr.gg'f~pgqwqqڜlA!ql |P'~'"eo#$_%0""g-p.N/L s1W++pFVsdX4xfr蔽sĬE؂8>X |k7F|dt3NsV 0R˿|^v||ųmX?PV}$}`Esz'ߧO<x07GB{w}WϷ_VU7"?4 sKwCW{gK8@ P eЁa@B(q"Ŋ/b̨q#G* 0!3NH"~ 9͚6o̩s'Ϟ> *t(ѢF"M$Br*ժVbͪ5k Bȯ@uod(w.ݺv;I$J,])r)†#Nx1cMFu2ʖUv: A<z8̆M,#.֮_[;`ɓף.|8ߏJ|`jW7j,`/콶qXfÏo)rs&&!17ZCȥN Z+ B8Q+P`Qi rsd䋃&y}n&3XE~;f3 0HGx7p/?0M<I#  G_ދhha8B$#g|DTgI) ?)e B=$ Q!| @4Cx p̡gPkx0+Akh#dz+EkuP+`[D(B"ڮezp@ -t0q1B 8E1ʉ  ! % a. ,M @B.%@x ` G|@jsЌgĶgOC{ĮWk/d=ܠACHADڼ@I3A%rj  c2@,H @(l2*h~ ,A>;4a  Ghyy4{R㞻Q X_m3P=N9x=1|vLC[#ҭ$ D&9$ƨ  Yb=Jp[JWR4a0I~`xPM1 EG:PB@! !6.||JrV2` @`> b`DF詈 @F d-7\#3AëYq Œ>tDB ` U7u; lhL `@ "_h)E ~B6@U`@2@ ;qhhcq\R1<~PHL j.`=|a a X!!@ vRq@αIDG=< ol69@|C =FIؙovK ̓P\#,A5]@P ~t\1`C0t@T xD0sA(` &Dp8F0`5!EmVhA`,#!1@ Uc@W_;|2iJXDǁt.=VkЃV.i+VT1v>)%{5Ht'TC AY¶!=#,hb7oEIOk%Ulmpg,7E/ %| l`w/P3G/+<'=0;H xB2D8v \9-lc cvp1=c&Xab@B0+k1arRoGZnJ`1HI/ !EėS^s<=wr~l"Y%Lsy3;_S3DGV0[KЈ|FҢKc:n1o7#0GD̋^FmkRK:tUki[tJ][#[.f[!q_<C><+oy iz;/xVFb'}۪y^=Kobk'|g?1'xwo >3|s|>oc_ߵF?_???~d~8 C%0 "`*2`:B`JR`-[_!*@ ` ` ` j`y`nma a"a*2a-JN `JtBjrazaaBMaDaaab "b^Ոa:b$ ٷ%v@&rb'z'b(("(p@)b++b,,'@q%b"2>cYb7_ DA"dB*B2dC:CB$C~;J DEbdFjFrdGzG.d@J!A]JJRdDKdLLdMd$O%DAPQ"eR*R2DaNz#/TRyT6NVVr%"VVvXe}%XƞXZGZžZ\%y%\v^S4e__f` `faa"fb*b2fc:cBfdjUM`ffjfrfgzgfhhfiifjjfkj]V&,@Tmfnnfoogp pgqq"g5r*r2gx7&YMRguZubgvjMdttngxxgyuw"E@;PK#/bXPKfp@OEBPS/img/jisec_dt_010.gifzGIF89ar{ыόn˦҈Sv׺脞t㝝TcrT[bUVV222閖CCDvBgᚵckss{ttullln!!!wҸHLPbjs}=M]:<> ĞHmcdd+-0xƑZ|øچyhOxwX餫 "~|״lԗVjf֤_uMrMQT\aluuy+17Ƥo߃cthե牂wtxfggзwwx򓘺y]enoc~͟鉩젱[Z>vNUUݾ#2 naR@ 6S`t nM3Ja怕0X`L+ spsAݰE0i"Qza "h6X;8!!2"%2VNH)ꪊ6"ȥq7b8FhVF1p, P&0.8M,P̠ 2A{d h!悭C))&ҜE1"ܢ,79; qQ ,A.G$d#pAȐ4#dO7Q@vt R@9?IZ4@M@`0d:GvTFa 2de]R%l\J%~ ̚sn*fTdit3M;36h1(:qun6M`G@ivAfK019@A-X s(٠Lwt9.Ž⎇dP 6ACCJ6 ,BMjyR)# OSQ5Et p (`Eh* "UVA _UzYj5H4RW ְjɗdJ[Y4;Ul[L5.zxALpl6 s 0CG s|=IOq uSH5opZP718Z D "T-8 C"`&K f^%*A aBEQ,q(o^7RU"냫(R~TE׿Xka7`KQZhF#,8|Y#"aѮxk(Z`93GuH(pCs4 ~4FowJ'1\wgZgxif!qWxC`<83S/('t4IsZ|t)TJVo_u~cDeg(>džXevq8qh<rƱ2=8~H$h~g3LqD73<8=C bT#8>iHWEوiHmxxH3)(RÌиwhKhgp3Qv W -8q~aSxI)/i SoE7#hEi $=@8D9HGI Kɔr"9w&i(_hQBZ;\9L^ `y-yȓpy.(Ӗnq s4ٔɘRdؗI1hVjsa_xy-afh9b.R˘chvl#^Au@z$iIȖpYyus'C9z7U^ʢÝrc)I<雈<ٖٙyxɜ#ihя|G)w, (*,ڢ.02:4Z6z8;ڣ<>@:(JF*Hz?LڤNPR:TZVzXZ\ڥ^S1 d:fZhzj Цnpr:tZvzxzzL:Zzڨ:Zzک Pzڪ:Zzګ:ZzȚʺڬ:Z:ںڭ Zz蚮  ݺZ" گjK"ڮ۰[{˭ J#p'*,۲.2;4[ 8:*۽I˽kڼ{﫹[+ *˛{ \{˵ ;;{˹%[k ś<{K”k' j,6 |K#,C/<\:lã"l;L\Ā¥RV3%\@<̚,Ü z˽lώϐ|qH ,̭|Ͷ,`,V`4Ͳ4`HѥLHp 91|?]S̥׌}B sKN80ݲ,}=]sM㠜ߢ<@1-5}ELMz{C~+YBƙmKKM+GMѦߞY }6Hp"n,klz1-Y N{ *0=|nxⓎA`$myK( h5@rP~z2.a;$ӗP^۽&mHok* Ŗn_+쾾q&* \u Hp   n{=~(;K 2^9޵f]NA/rPN?4=^:oN1/@mۦ&-= H} xM% ,!/b* &~}d=V0H&? ~P޶Nn nO4 4 #A&^O#qHm ^쬾@YP2qN1l+OЍH쿳 X8a HPXH(C%N ENP #!E @Bc˗*aZpP7-аaB  ‚K:|+E #|HU1tIL$N\pY ^"jǛBZA (PD'Ã0/=u@ vXa ]-- PqBN}4I $BHN&Eۡŵ߂<]܊' lЧ}-\:|M߾A}er~UƥYAoڷa'?t,pCBH8HmpPB :9 +RzO%A< Tق2AOJE89cK7rp"oK.R+l2ˑ8\5 ]3h "3*4266d9B " ,V '&5+pœO@bD Ch!L+&2+*5ټ»ss-8"+b1$HWK YSfæKm9( )3uu$b9N_]XcmE6׏ͪK|/9*Sem,~'7[ /rC >ËbI1_Yeb ?$ts(2DgKrA+%%{Kh28)N@Weoki\M0dN*f@ܥ24چ-pv3L153iE3Gۛ")P L5~H1rUFOQi'4} 98QIQZKFndK0-mImʥhOB,mQU5.wAA(pABZ£*Ɏ$i @g$_|֗;3d Z8CQ=E+CT,5-a(THhu m&X':t!YEյ `06lD[vqm`UFX%ҁ$\0/] *@\X: ^KҒ c'rXɖo:R׿.}m{[XQ/#znӾ4.y4Xde"D,Z%OƬ.~+ԶU ~T8o#)wѥq['XliR>@!Q3JAll=xYh)FˊYlCBF\޲g֒wl&y˽\g>}.tjg& x8lZ5 Z\.60ru?^\c,cSC8<2O?6IGMSeʖ׺;^\"NMC.vXmqYl_\G!Ϲ^Uչ7IҼA+nDl>]Baéʣ0D*:h%ΕDq!\M,fx%vQ_ k⾛J&Xn~'s@˼7WHre;rKNK[RJIyݬǙU =1R><;>?7>\ :M%W:uJ$/߄??0 vR><̣yn_OCOdRf컿`#郿+@,a??c>Ti >?m³l @ @T@LA?,8 L,\pA B!B",B#C?C>a@,DCP.GaP(!v".b=bMbV]b&n}b(bb__+V,b-.^V/fV0I2N`=c4N|``rtƤʹ! a٤7(R0!3P `&MFvwa7c.8N0`T[@aF΄tvz&pvPPvtf6F`89RdH "Pb@0PJSFXTQU^%vW~bYeZ&Ґe\e+^_f0c-f,ުDplGp.>Vh7"hdHV"fa hPfa7϶fCzmV?fnla79iieeQ&j[6&EߥӦvj߅jbꡤjjfff̰k &zcp5PzV.hp~oCkFRX!xH5cV5&䟘GL&hddA d'?dq>`>hCdV٦pJ.iJFFdRpCeNn%niW.j~nngan3V66L.D=˴flNZ:Huykߴk7(D.f|VfXmxl0l˶l 7tqav ap6`dⓦpv0("7r$Oi&W'o(\*3[-J/s&2gO8^4W5klf0@o7M@|6gYcxVa?`dOONnͭq pNAhE9`vN 'f8K&MPN/q 80qvChR =VWYnune^^j^r5`a'v0_cYg^ nvggTh`D0ȆpYXkFOpsDA(d8kێdNaAIzlюЁm&Wqm 6HfznWx5%7u_ywIj7vnd/WyOol:Pp.Rfhӟ.hpsqp&wth0N@0H_t6p=^co{xhn&oB8Bh PU&Wß_Zg)W]ɯ|bV:a Bo *a'RHƌ7rbȐ"GD`$ʔ*k嬘2gb&Λ%J)R*ΠBKYtҤJ2%)ԨOPj*VJZrꕫZÒ-kjײmܸrҝ[.޼x0Ċ}h1 'SL̚7s 3Т(miOWnزgӮ[ ,}7‡?8ʓsh9WPn:vIsLJ'h^ :2|" <ү$~+|%MƔ6ek 5S :TF~u!]YnyV]!^%}`d1Ffuv㍣j=6$[o$-rI9esYiwYx癧^B5|e^d&Hi0 HS.xgP٠}Q!Ve8և5"vW)/xi 5j:n#>$yjmG%M*G%]ykuYz%FxY9Cf;_~f~oKsY'Nx'IgVh{ãF ؤU"2nZbZk{[n&*Nd s+úv+úűf*,:J[:Y`n+a ṍ׺kػ)@믪ZCp 0wo)1zk}1!LrBr{aˀ sh b#޼W~s0X4Mtѡtҭ-}jӬBQMWc5y\Az)|dmHh:kضo sOX7w{շx`Xa#xeظhY3OXxuبǧz}zjN{U|G(uHxk!^WEyccHzWeO{ Ӽ=1G|R"ߕ̇qm}+?O$d7 v 0C4) T'LQp2 ?Ap4-'%9&}'@*Ё=(BЅ2}(D#*щR(F3(HC*ґ&=)JSҕ.})Lc*әҴ6)Nsӝ>)P*ԡF=*Rԥ2N}*KRV*Vի^*X*ֱ VӪֵZn}kXaVv+V׷^{׽V"k]X^ GnFP,f3^v,hC+=-jS[m/j T-gG[ݪ}-pC"-p-tM\vr\:t_[]nw]׵"Ad'k6]/{E.}okn_P^8mUε.C8©pkVgXph=Z7%6qgQYx c4;[v11i,ֱ$+"*k)S,/$bsYKq_s@=b)>5 Q V"4vׅ # % YA5 ѡ1AMU%l9:Ahqׁu_ñ%ڵ #~]Qɝ1va9YA8b]8Z`c:iQCnס=2dl0?E$:zY: 4cH*䵤4gɁ Ѐ xLd52Qec9 ~VJ" +r-A\He @艖Z@ǁ$Ui`1eQ96g@@(gUg]%GGHjEe@HZ%=`%HI PcNF (gdh/% lR"]SFJzVgA Pg V~$WhdzP٥6hh%m:n`fQfݠ h*EV MBsFHPENFYY6!9F j*F6ak r rɧW$o]}&p~ EwzX~Cg} %tzր` uviV$Z@ Q_qhY+@'ga=&j rRl $F8ai:afE(PMrlh^Pɑd a"JKU^J:A8*Qڭfr$~TޢT6 UҤڨYu# 9"h٢b\_> (bg*GP&&fm%f!>bP@n2ր2j42i ~ొ$73&8%$ yeRYy鯉 n(뤾&)IdygM~/!ިgꎍaPa.&ƭ~^k!nZB)ja]B%u๮iW,n&eř. |LlQelOM(ffs+hőg*j.,>"1K(a`ȑBk+~"~XnHIZ=ZiLjޘ*8j\*âUԪk۪퉡,Omq_FB$.&]*U^jhkڢ5-kr^랬QNY.nmvyigfb2ђgAgvb:z"J.fBV(ڙdfVNYBґenY/nYb~B..Wbf!E!(ݓj{kJBp*wo C(boưhYkNj%geAۙj"󢮏)pOE3p Cq-1N%pOq mkm>f]vzq8%yM5q[^/ .ooپ0 qjMq[1;eM".m`R"B#"70 2rR  1OEp;ro,"r /;.,-r2+3;p$$s1t2M12'sN7re1%#riqL16~.14G;˔7p6ksoN?3; :dzA><+s0 s>VG948HB'q"C33oOiG?NVCÔ7:oMRJ3U4A p'>3>+=xOoK<lֻ22lw}_=kS9(|뷼|=%'Nժ][E dpbD)VxcF9vdH#I4y%GXy#3i> 8"EKUX3P:Dp &ASI!Ƃ?u„\ w-2j dNPxĴSP+POB`u)ӧOZiQBMpLf [0L$ujիYvvl߾eޔ]4 h\(iTȑVL5,k5o}0}wt[@0Z;h. 326#@'M X#Hj*  1kY<P၎&) '( qb(0$14_aM6$f}h !OE a>f$gPZПEQ"("l4d^x-S!>ti虆-G -͊VߓR G۵Ǽ0L1"sAd=v]]vVp>V(VPB %׸u.GexיPG6G!JJW< 9 &D' b\u/^@D~"MdM>| ?<\pȹmMxB$;Ow#lviU.NBvBXl:),uc>p̾=Yĭ%`q\ I &_7\R ~WiՎlH0}Uz KjffPSg) aMGb!1mnA b ~EN{1 {6@BEP01\94Q)1 i%0* 0| `FX0Xz [(E@b-"H ㆸ\O`?,NÈiC&0˂3P1T*7R,c H"F]qF- 5hƺ.H\VnKb [g  "Ie8TII@;<1MQsxs>_3UZ l@Pmy.b$&| LOuma8Ԡ q&M cfǐ7o:oA!Yr`APUҽGRyHMd'Eh!cRٔ&~U]욊C+ XnѢ<©0nGIUb;DkX`qb.Ֆ2p3M5HT>%'* Egmp  6b<^D\ՕAQ{5v, %;YTXV/8HK}?PX O=A)X״Ȫ%žT@0 AT@| \Z !&L5ɝ/gPF3A"ecW^G$ltͦ{# ӫ q"}{11_'?eV"旞C' CbL`2`hFm5C|5!I &Hه:4,ZHj{h l#4=^ 2p#'YK eWzNH5R`@p`f B@aQms3&(Fذo˪>Y T&!F4 0t  ѷn!J*iʭ2`1gȑ 2,l{)dTԢCa]q[,ڸlp#j`K~I090kARʶ+P>x48>Lq At 5AMp$\NXp>u!^ LLq;l26 X5yAz̟A6b@fr9W\0vF}⠫!XC`-+x b H0@Y@4Ͱ69SB;(ܩ%p^}  ,>x64a r`H/a>  !@kKޘ!dLC 4Faf "+ia(v?"* \ ,.8(@@,h"bE Th&(E*@r ( !h?bAa  z pXCFp` A3l<. ` H!{PG1#~,FO|XN]" 2-BB*p$+$`tA@ ߰LX h P 2`A q-MGa$ ~kAZX,Ўn9Q@@HQ !L1j =a] D:اV|@Aa ̀%#?% L'!q t @ >1Z#ձ  >m$1l֋Qڎ;QC r ؐ,j,=DnjP.84QhF$$Ɓ1@P hiԠih؁`(11) fd*5+9@ ؁+R7O,̓,(!,+5p6eVJP 0#+3`drNUi(sr]V` 83@zn !@ EXdd/zd6` v!ty7785n0B|!C9].qHm*) q0(E& aB< Aԓ^(rrtO5%`4s/Jb/Gb0%1 L^j PR(J S?5T (4OSU d/Mk FA4N1+uYGV(YUeIZOB`PqN`[ *FF(F( ^2E$լ$AԀ @]^=IS_ 5?W5@]VVa_a (^Awu~mc5VXݴX5Cd󖨚WZ[$6 [ u[f @lܥ< L @++&! uui#*5j Q<@erHSK`` `Vlwka``Z`(` ! @m6n7cBA @owLeopG\abVfpF"LT#HL@t`t#귾^OjAUjWwj`dU`6wÖw0af&m q8 zz6cuX{Չowew$p5*gE!> > 8wL]uXu>5L(X` kqWw7;CxKNrU8czz9cYzI|?T X!O/IE І} }8p6@$b ir_eAj (xkX嘎AXI؄wWZ8wzX5ٛg(#y.)EX}QW*!*ڀ ' ! ak9rxՁj]Cd'ǹy\Թu ,58€i76SWT 1ڠ 5`1v՚yףx Y{4C@ p; yDpia$ :y@uTB{[Y@NJtD6au>PU5. $@k[5yw;?zE7oXLzOY™5/a@0 pΠi4؊W*@ VvazMS@4Uwoak7z…ٸMUzY 2Z`]=}]]'Y~ S=HȩWǕ<` `a`aDt@6a:@j;<5M $?%\ :zٮ;ďULBHD֝_k=v`{] @ @^no ">ˁ y#}L-oڻm1>a>`ԑ8>*`nw+u< ``܀ʟ/qCc_G m@%d*X .4*[7}5p/i$AVRg_=ɕ\ya! ? a bDA>`RQC 2!ʂ5:맽AYaN >1^~ @> l0ᄅ 'x"mX);r"J<2ʕ,[| 3̙4kڼ%V64Сb=4Ҥr&qՋ!*y$@^x`ں B@C"ͦU$ܤ&&&KI)\̘/H8yOԏQ{Kr1$bL4Z;Fyi,z1qD2{4:84h8US%Q4 "->Ph3dDڻ' ۿOɀe/ H`(E DA%PC ED!E]dFyQH#]b"Hb&D5Q. T26uJ`ATEԓT[q`$fgtVsU^&l,z&ecX,gJ0\(pAdS#JܣfaHMD3NiZkmo'qA 1\tQ{")|BNdWy{͇_zÁ* 88 -H8!YjDR> mҢȓO/^ "EPE`(LU x_Jc%9p WrA,$ ,yj3B;yсU&mfvg ф9^djFhݖnpEAr5U 4g0*y桷{·*}~Gk+ ;,"뉲~8mf)"nmt0 Axwe$ CZjJV@&DN`PaSA(d?# Y'g QH4}dO$l(ʉ̨3Wjs&@&첋@:tK3ݴOVA^5qbvbsTNiߏn7 *"@qm*`؛0 t,rW䥆)-q Q"B`ġ ]<`TL! BRW1͸.c# B!(1(BQ*[TeLfK.LډR U,`6#>n@#pBpC30(Y('Q|#| FDHB#`m~.L֨,c$:Һ(+uDQXnLD2H@0A6Baʥ%`0=#"C @ubŰA1  A28G4A,1ebY)Q: O!N%8=hD)Ja4 hc g4A`WEFZ WڕA0lH#II"ӤMoӛ'r:(6ʼ I]q  F W\ "*JB-jh!(@f:왒 ,v=id!QNs4])Ep0]xHUwH+>@+2vf PvYPO0 50IlȌ"l )`86#7- zT٦  fPGP7 Ugօo.dol51]@|Nwc7;N֗ԇ"}~4@~gPPP(gQaP5#y& #vfQR[2U]Wh(hF^&Bj*j&khk?7_͈Y "( cy(-}$^Q${8ـ4`Q * `f bq84aTp{.Lx@0W|D yE0}T<$~FCfFkg!I rR`yR(P G[& (pEP0[Q358@R>`5SVZR>s!6VY:d؂ -K7V#@a`  89JR` )\P<kRcpC'J y( u#gEcF f8j*< K@ !5>SRJ:#]d>Q*2,Xj-ўbo3eJ`QnZZXf pzooЧHo{: p@ ИVT-!: 3H";>sQ),벗02ˬFCӂ8 k)DA[Dk P nxULrBLXTp )`)û^ e i;  1S9p) ː$y+aVz aփ£[?z;R BH븽k+l L;- ]  $ E G 9 oo$ûV'9 [k; e w101f,!j'Zo{N*O2Rt< =` AEê+K+ 5(,̨j3INb@ CђmЍġ1@ ` fPI" x`$$@L'Fa 0[k7ڱ `mA :QKpa+ ŏҰSGk` d^=+cki !mƓs;pǜ? |\6gR1 pѺ@ P O %,ˆTt90 GP @ʧp6| À``B,h{M aĺ|@W̩`=g RZUøkKƲ,7U,آr*z ,Ia]= .vPLbܠŰ pȻ)q9, J *511^pM<ߋ)( @.̼<6} c>9լl^9ԧI0K`<Q bpʐMS0Cz 0Pq :ժp`mDKC 0 hm SLذ p«{ ŀ1);Zؙ&sOQTLp`4 4CC0`~ ..%@^^ʌ=0=2*#"m6Uԭ}QpF#pη2 Q35CiQo*|f9z` 4p u` P ` '=WLd}t0 - %m)c͠OPJPnNm.Nn闎m p~I8(*.pFpb@ /=P0{FgatCmu$dx]]p[^S_$y5Bĕ|~dd`NLDߞJGO# ` {>;@/Oo V`pa N4"-m*:zSos!vRݶ7S`Q _Nދ!0 'R\=Ր> gڢw ;*0 19 qVw<)lplVjָzl/۰esT Mɛ &T9p0T9me0)`m0ޤD==um&r ޷0 ` #pe0p `0V `r N r/O]vo2kp L۷`0O "; @ D`;Qe) 6%}A@xGH9@]&gE(I-sHZ@vjƱ#zуS*D;T֮]łc'b0^Ś]M?F)%P00?zB0h\TArE9s5 !  k搗&x@ȃʔaNvA(->tFZj֭][lڵmFH Hp~lYƉ"Yթe@Xq8Ċdʖ$ߜojQ-SH_މ}#l,  09+z+VF;f4Y1 #(c &22:F㣞v62K-K/*jeT$qWPΊ焣@ '$.L {h v&ȼwل{>5B$i!w9't0BaWn埂PЖW_ 2[ hK'EةVgk)@m $ ($?|oMTLXN`gFpy~i"DD\Ѕr >[Aꐄ*c fOƪ0UvHHu+0K0W| j):f-OkZ-lgҹDC ωOb6& 8z `@ pch@ C6@],sO+Ѐ;1ZvĬTyBB*ծ)NI^/!lH,oZ=mq#۸D-Re,e9Ы7gp' N7)~;8ܐ^G 9ҧsQC+\=ztF0:Yuzr֙N`gp\L!4mœPnyZYf\HL۔AKVԢ%-6tF1薏0 C変3#"n쏦[ U7*tf JJyByNɃdIQdRxOI2Ϡؒ)PqefEW0V5|ހ 8xp\o DQuøTD aV?\u*EБ(ʅ0KACYC4,*ּ Dymc5Cʭnp*58$# `TwҠV(4M,iGS}!MHحS!vhЋDY (l*2[;%YW…p%nԸgR.W(E@4eJ+ƶ;d) fE+!xM' gkևZӷԃ;PK14 zzPKfp@OEBPS/img/jisec036.gif1dGIF89a???@@@777楥mmmߟ///___nnooooOOO ```ppp000PPP;;;)))rrs 999𲲲{||rrr{{{fggvwwDDD!,̏ /H!TP‡#J\pⰆ,jȱcYa Iɓ@,5r˗0)9%͛8sSYC@ AMH*œPJJիXjJ3.K,5QpE+H qܿq`$^ uc ?+2c0^H:x̣<^(dcܸ 8 B}L"H=qf@ C  Ȥ&7Nz (GITI֣GxvL+Wj.ǰNjiK /{_#8&1kfLb &\Ś9g$Ҍ5ea͘`3,foRd 9ws,BzX!W"Υn h@M@YWrІ]g\ĊZ|[%y+(Rs: ,`Rd!AూL!(!$ Sȴ 4 bÞ j):է)RIT84A@:XV(gO8Űdh vx[7W}$=!;S UEkd[꒾c$z  0A@s:6J:+e'bY|`PH$!NY?OYu sTg]3pGl 9zF? A=9T%ݦgUxU>d?ڛ A|q?'վ|4ϧ/j?~n}{/~U|(2ď뇿~Ga{g8P@e7}<ŀ_w x h;" H R01x&:xgvRS68! Hh NGp R8TXVxXZTXDŽEdXflȆhj؆mSHtxvp`0roXd8htvćxia8Xxx.}($Z9=Lv 8ӋE؇x βXֈO=8͘ Ѹ ޑ8̸e؎' +9xޗ | ِU % 0$0$`#!b)]nS#2 '`  2Z:Vu `'p%p.ɓ!;!@ O)AP%&!B* `*X焓uGQ> @PX,Gx!rV0Q)'$ #9* PIEu*0&) $6$nJ"!`6Icr#p$@$9&{u:0Y )#=YIX ٍt)) /2R&P ٚϣYә`t)i) Ip'@ &@#Cy՜s_cI`lD!*`Cy@I<(ƅ>Jr''Zi%E'`ǣ6#Y}BPFäxG$餧RMQ6K\ڥ^  _:dZf: 蓥Dl:mr QsD@p+FO D`BUT1Q PEZ TzMڜjJИ3Ԫz*j: JU \ի* UzMj3.Q.5DF*ZF<s[so嚯뚡ZH(u[\a?ޚЯ }jWDdڊ j($(=7 Z@{E % _в t0ః$.CoDFj"J\8 Dd4#['=+?C+iڵ@#h{5I۶$ G`,dX˷l뷪 fepW!AQkzj{ s0+@x˰B{?GSa&; 0.P7˲Q[{}˵ɻu R} >v6nb2c.:;뺜۸ >]2#lFV {hhbƿW[{@\3R#.܂q[, v 5w8p +˸è BFB۵$M#,#B51&npKDZyzċC %%a2&L| CGPhi/ >첧Lal&^E'~\6= &) 0bs\f9+ [L:'SdfJU\{‡L C2e"*Cݲ5<{^bgRbfb<(NL nGscL Eu; : j@.):*քLk|,}\Υ-)bWB KdlcP6jDY,95l u^0 }ъvT:p1a5V'-T)]+Һ+ӫ;ckC6.VVr|sܺk "p\dP1-͑k O5֤*ӱ ӻqd}f}R@LXmwW*o;VMټw0wf,.xy,M  !#,Ɩ]{%6&c9rK/0yf =]M ƓMۛô͋p]065,4:!,| Dmq*78FM͝t}/{&6,2`5)1iil}>b/^N0u!A( <V.}KBIn?tvx~T~b~aނnE~KE^07B-3^}ElEgFitxi~4N猘Nn~yNnus^Iy\y(k naIDJ~dJ+;J`6-rQJM0TUj ߰w얾OS_ `.q}>&S++!󇾬SƁ̤nH1$O_aF_Q?MJ<N>0O~}n_y23>Ilf{:/.qVQaR惮_R-){,P7ozA^ s4/O|O@!o@?PV~۷~?O`D`|jˏ//,x !xhz_R '*(*"%  $"땱׌Dž  <(H>0D7D(ݣUGrAErjF$KJJzM(/Yȟ@ H!CE F "@CpHS ,ƠѪBL\kG^~ fa7)<'@x^N(RgiTDSy7V]}-$V@ .T! BTC M $`Q jL+$bZz = e.x!w `00BȤ_d S>]Urz&TH& ]'vqwdXYbzzi@@^ "^5~xpS\a^"")@9-2BSP]]:]bdݑGٌ6'tgl/K/ dP [:Uup|ɩ'׊ uz ۾@[lBNӪުg",6@ESt:S PA p kX%Oզ$ H0p'Ae0"${{JR2<4:P sm$Є7G.W>cg$`Sbt$%V :2%@=h @`y& yx3WTG/w.n=Zg:+&zhH՗OK]&Rͷ4/[ZitzLzd>/~l"4j`"q Z̠7z 4͠F8(؏,CTj/((n(DfЀM t$t}5y"g أ->/ lT/VHX7LKOOH&&̉YZ(E<z)6^⍱I #"p GL@4\%HA~L83Ev'>B [&FwdA 9d&wMza!-HhݡЈ3KE 2xN'fY4)N{ӠGMRԣvhC)֩ƉN^e5kLw|K/˟{_o3nue1+M;/~ Mfgב6jmd~Kpk msQt~NǢ&/ pF? vMfvQL{k‡(gq,0gN8Ϲmh7b;ЇNv;}=w"[LOKu{;A%A^WE08H}./ޟ I,L};@cB wT!P23"" G>0y45󐟠PW)AӘT;"T jCaY,|~#EqB:  Zz~ ^?"GAH~U PS@PAD xG^!{]'wwxYs~x𷁋 t͑  \ ` _h> '(@}) (P1 T7>8# ) |}MqG|~y |X5 }(1 ) Go(}qX wzh}g}~([-y8nxc 'qvpyzwJ!Wzh>-!ՠ! ˘sqBǂ&XxX&uݨ!@݀ 00(X>vȱ< &P p gbx8i'@ ݵ {@{6%P ُ7'0}M(~`{ 0M ( A^!xETFyHJyA3P`&!: w BD@4dYfyhjky~N0P R &w&@ `  _I^n0 `ُh ]+0Ԣ`P@q[H@yЊ,yT)̵ٚ雛{'E)ȉw9[ٜq[5%֩t Zڹҝ@.?)pXaY<pqYp"9#)r c*j.j  :hD}1nTaXXݨmM3⮖P"b2>4^p(* #=FN=8@AK'MSXeV~XHJ^Kܵ@O lh#rt=Ҁ 2~-`. #s2=! z. I6^^j焞ݰc/kS!( .>+k,Ae%"~D;gTy\d A> KR-.*e#5t00al>Qp24^5>> CЬNaLt} -oSG3:>Ot)??lq.?q*#)'}2?P&8-m6@_%)79;/MO'Q.>mRs]W5dBD/FoH/I6~/a_kmzOߠsi.F;jl/ OEx9aYѴ`Oh9f~*C'Oᅍˠ?4:8!:*A!ի2{;2-"a22kW ?  m/Ԩq"իXƊ1 `JDf %AB$%,"gA ȳϟ@ J@O ""5o'N:*5q".a)_ U`Cʈ2lx5ӭkݻx˗тb 1M*a0PUIb̖^F@A 0]P)#g2ŽIξS^ͺI{I®Alsj- l-AGeUƘ .Ni=WË=^8^g^I TAD0ng`_|Ngfy'v4aiޅh(h'(0(#bψWU@) =eH&dCcNu5)T~WXfUnw\d 24&ffqiEy8Q^!5xj `,xcT{ %f)"(@TQ5XIm꫆vJѧj]eDLG]*qz @ZӍ `$Jh엤H(vp4-j+lbݥ+"ۏeKdnlpx(PRW/}E{PVK\U8xa›,)ۢUPm!Pl-笳Oo@˞H'MNϚPtNGm5ScZ\5[w-v_h\gvkt k|߀.smxn7G.Wn72*褗n騧ꬷv숆.9_@'7G/ ,}0c㗯>w >oh"4)H:'H ZC  GH(L Wv0[H8T c$@ H"HL& 1?;PK[J11PKfp@OEBPS/img/jisec_dt_031.gifyGIF89a7𠠠EEER\e|cydz惜׼ݻŐUWYx47:sssp񊢹ޔۭΊ૫лڝYahw$')ԶwhNq£rvfmukrzLSZccczz{򛭾۶lll?FNҐٴ㦸jwjԸǸYgYXhxFKQ.14Ų֮äŤʙ_ejGSGdhmpuzj(,/݁8;>qyŪϪbbO`q!"̴冇Ԩ.7.Z{ɸѳ9D9`m`әݢœsٳ ߿篯צapppuvumOOP@@@ș___ڏpggg,7 H*\ȰÇ#JHŋ3jȱǏ CIɓ(S\ɲ˗0cʜr8sɳgL'L8ϧѣH*= 2%u0ҫXjJqcʴp |N]˶5d Ȥ1s֭߿\:#%!ga Lk+'+1:9٘˨SκFfjv29cQr:2ڰaDM( _a|Nukpu.o,ڲsXξ{^Z=tx[͑q{&aD&b/ ~vȀvj1bR+2a ^h#`ƐH)H=*~ēʑ1:'44PF)TViXf\v饗ܘ(4K q('*.(rʑtƸL Lr8/ A:J(&6!D*!c^dtb#ꨣaI:ƪZͫ*­*Ůͯ6 "&l6,Fb.E.j$f9r,[.H:zRz8ZDc:.무ю03 0DLMTLŴtq L$S?C7{g37S`f7t38@DMmGSB 8S $v碫.8{opڪL# 30Sl1o!\'o-,5,;sE}4<)NCC9?Y #,\ʺy ^jvگ pKwSpw{K|S_6>DMfLPs,28Du6*wJѦ6V=mo` Jkyt98YOKNlOj w9 4KXQwCQF@H2@D#kJu'0b )=h1%d(>9ꌎKǖ@`Y3HE6{68QPϓmcۤŹně2JIocLh 7B5rqn\-oB323eL~y !2/Zbl&!\V&@Jl&gW`ęEQBC3 ,lZX'ߘZpL)N|ٳ 31'.sK %8< zo5|C ш:|$51&rԣi&MNˤF"0qӜ(e80 5 PTt0!g ¦r#_,W)!(W]D൯+Y!LF>Ӣ([wuԒE\EZ* RĐDHm0 @ a qsp5xST),P=-}WЂdB BNS8E;XP`"2l)UR5}EIՃhla+۲ֶhZ۷7.JNV&4 7؁& dH怈fYx@P<%F@ JA `1_0Yң! &\c0E*p4aD&@A1B S`D(aGE\tHc+V==[P&tWDLWsA 8i$J@@h %fl` %B T4#[bfXX)( 4թO@h;in#!j8\ţnQea}M͚qw"OB R\ <8%1Y8f:iL@IX ޭM Mh)HVS8UY?Yp! t8<_l:qF˜F_ lnǾ9^?ߠ}lDnA!1( 0Ԁ(}nnhzS` [8D?L Be=F׿}ZzS5;Uc8.RVwJ8αM}4v-[ژP̡n;FyG0pa`σ! P_t1` #0 'uW2 6h ݠ {{|tvT% l ɧ|o7j|7QGc/[c}}TR@r N` s0 0t7<pr DheA @7spRͰճz=@ %c @B0 nF hmYZ5v<3"8K`PvǂqbcUVGqKj46W"\GE=vWP+RWk<`7|1t3OKFLBTc7vh!Fp btgV[5qWq;cHx~Rłs%<JYu&=p7pH9!p L ,|7uX}nu}~Rg\Wt+7<xa38J%T+2aUh!&vP p.H(qwcrԍd40/UEJS4莶)B{-($!`9j<=o7Qu0Ɣ&OYkIh[樕=A$i'Y'd,(v.l9Evy,|bGuԨ}t⃆ 7) 7S摎NCX:㙟%@搂Ѐީ?.}5((W8RNtqdJ`S m)TY}iY!i&HpCI@~q((򡊢(2R(\)c t*%+Y+Wt"Ai,Xe+-蚓Y3p\zp ~'R(!J}R鍡,W -wN:<eʹ%?!@HJL )uP| _'z(W)MnZؘ7{i+OPř/aw *:ZzȚ !j zm꠨JviQ [ k[^ b:(wT1zYI*F]`Yb=(B.yTj3@GP$[$P[K(P(| K0$[K(*:..k2;3V88K< (Ь%jPպZ+qV@6Ȕ,檩"zcj/c*0}s4N%Dv>@% з  70P@;;0K1p{5й5y@ к @k 6 `ʨxp*@ Q{ @+arY멀BQDfREzJh4՟{O_ZHZUE4u;%w{@|{{0 [9빟[ *3YE:k( y j +ɫ* ʵ{_@7JkNݻʧHU2K*s˾v+y+@+kK븐  L1`칠K   \Κ p)G{I