18 Securing Oracle B2B

This chapter discusses the security features of Oracle B2B such as the OPSS, roles, users, keystores, and security policies.

This chapter contains the following sections:

• Introduction to OPSS

• Securing Oracle B2B

18.1 Introduction to OPSS

Oracle B2B uses the Oracle Platform Security Services (OPSS) framework to implement security. Oracle Platform Security Services (OPSS) is a security platform that can be used to secure applications deployed on any of the supported platforms or in standalone applications.OPSS is 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 portable to third-party application servers, so you can use OPSS as the single security framework for both Oracle and third-party environments. This helps in decreasing application development, administration, and maintenance overheads.

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.

OPSS conforms to the following standards: role-based-access-control (RBAC), Java Enterprise Edition (Java EE), and Java Authorization and Authentication Services (JAAS) and provides a security platform that supports:

• Authentication

• Identity assertion

• Authorization, based on fine-grained JAAS permissions

• The specification and management of application policies

• Secure storage and access of system credentials through the Credential Store Framework

• Secure storage and access of keys and certificates through the Keystore Service

• Auditing

• Role administration and role mappings

• The User and Role API

• Identity Virtualization

• Security configuration and management

• SAML and XACML

• Oracle Security Developer Tools, including cryptography tools

• Policy Management API

• Java Authorization for Containers (JAAC)

See Introduction to Oracle Platform Security Services in "Oracle Fusion Middleware Application Security Guide" for more information on OPSS.

18.2 Securing Oracle B2B

Using the OPSS framework, Oracle B2B provides security options in terms of users and groups, credentials, identity authentication and authorization, policies, keystores, and auditing.

See the following sections for more information.

• Managing Users and Groups

• Managing Credentials

• Managing Identity_ Authentication_ and Authorization

• Managing Policies

• Managing Keystore

• Managing Auditing

18.2.1 Managing Users and Groups

Using the Oracle Fusion Middleware Control console, you can create, edit, view, and modify users and groups for Oracle B2B. You can access the Fusion Middleware Control console from the following URL:

http://<hostname>:<port>/console, where,

hostname is the name of the computer running Oracle Weblogic server and the port number is typically 7001.

To access Fusion Middleware Control and perform tasks, you must have the appropriate role. Fusion Middleware Control uses the Oracle WebLogic Server security realm and the roles defined in that realm. If a user is not granted one of these roles, the user cannot access Fusion Middleware Control.

Each role defines the type of access a user has. For example, a user with the role Admin has full privileges. A user with the role Monitor has privileges only to view the configuration.

See "Users, Groups, and Security Roles" in Securing Resources Using Roles and Policies for Oracle WebLogic Server for more information about creating users and groups.

18.2.2 Managing Credentials

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

Oracle B2B uses OPSS' 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.

See "Managing Credentials with Fusion Middleware Control" in Securing Applications with Oracle Platform Security Services for more information on how to manage credentials.

18.2.3 Managing Identity, Authentication, and Authorization

Oracle B2B uses the Identity Governance Framework (IGF) of OPSS to implement authentication and authorization of all users and roles. It replaces the old User/Role API model.

All the authorization related entries and user role association is stored in the OPSS policy store. The OPSS policy store is maintained per domain basis and each application running under a domain has its own scope in the policy store. This scope is called Application Stripe, and all the policy data for an application are managed under the application stripe.

Oracle B2B uses IGF for the following:

• Authentication: Authenticating the user against the LDAP user store.

• Retrieving user details: Retrieving the user profile/attributes such as user name, department, phone, and so on.

• Search operations: Searching user role.

• Role operations: Creating, deleting, and managing roles.

Oracle B2B makes use of a resource-based model for managing authentication and authorization.The resource-based model allows Oracle B2B to:

• Provide administrators with human readable and manageable resource definition and policies.

• Enable rich querying of the policy store for policies, grantable resources, and policies-granted resources

• Provide a single unified authorization administration console across Oracle products that externalize authorization using the OPSS Authorization model.

• Leverage advanced authorization policy enforcement and management capabilities in the Oracle Identity Management suite.

All the resources that are to be protected should be defined along with the resource type in the Resource Catalog before granting the permission to resource. Each resource is unique and represented by a name. The resource type is a group representing all the resources of same type. Resource types are defined with matching class and list of actions. However, this approach neither changes the way authorization is done, nor it has any effect on the authorization. This approach is recommended for administration and audit purpose.

See "The OPSS Policy Model" in Securing Applications with Oracle Platform Security Services to know more about Resource Catalog and the OPSS authorization models.

Oracle B2B also uses OPSS' server authentication providers, which are 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.

See "Configuring Services Providers with Fusion Middleware Control" in Securing Applications with Oracle Platform Security Services to know more about authentication providers.

18.2.4 Managing Policies

Fusion Middleware Control allows managing system and application policies in a WebLogic domain running Oracle B2B, regardless of the type of policy store provider used in the domain.

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.

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

See "Policy Store Basics" in Securing Applications with Oracle Platform Security Services for more information on policy stores.

Using Fusion Middleware Control, you can manage Application Policies, Application Roles, and System Policies pertaining to Oracle B2B.

See "Managing Application Policies", "Managing Application Roles", and "Managing System Policies" in Securing Applications with Oracle Platform Security Services for more information.

Note:

When configuring Application Policies, and Application Roles for Oracle B2B, please select b2bui as the Application Stripe.

18.2.5 Managing Keystore

Oracle B2B supports Farm Keystore Service (FKS) primarily along with Oracle Key Store Service (KSS) for keystore-related operations.

Earlier, there was no centralized keystore for Oracle B2B and other J2EE applications. Each application created and managed its own keystores and it relied on using system properties to locate relevant keystores. There was also no standard or guideline for keystore storage, thus leading to several keystore files scattered all over the file system. It was difficult for the security administrator to ensure common policies, such as key strength, algorithm, and so on across applications. There was also the problem of trust management. Multiple truststores meant that even applications within the same domain do not necessarily trust each other.

KSS provides a single storage of keystores that all participating entities (Java EE applications, WLS, OVD, system components) can use across the farm. Keystores are stored in a single repository, which facilitates backup, export/import, and migration. Access to this keystore repository is provided through standard JDK KeyStore interfaces so that the applications do not need to change much when switching between keystore types. The framework also supports a common truststore to provide easy trust management. There is a root-level Certificate Authority that signs certificates in a staging environment.

Following are the key features of KSS:

• Provides a common trust store for the whole domain for centralized management of trust

• Supports generation and storage of secure keys in hardware devices

• Provides secure access to keys and certificates using code-based permissions

• Supports key password and keystore password if you want additional password-based security, which is in addition to code-based security

• Manages keystores within separate stripes – system and applications

• Provides management support through Fusion Middleware Control and Weblogic Scripting Tool (WLST)

• Supports LDAP and database-based providers for keystores

Oracle B2B uses KSS for providing transport protocol-based security for HTTP, FTP, AS2, and SMTP exchanges such as:

• Digital envelopes and certificates

• Digital signatures for host and remote trading partners

• Integration with KSS for storing all passwords and security credentials

• Secure HTTP (using Secure Socket Layer (SSL))

• Encrypted Key Store password for a host trading partner

In the KSS framework, there is a single truststore file available at the system level (trust.jks). This file is used to store trusted certificates for all applications (such as Oracle B2B) by default, unless explicitly specified as something else. For example, an application A can either specify a file stored under its context to be used as truststore (say app2.jks), or choose to use the common domain level truststore (trust.jks).

Application stripe and key stores are managed either by using WLST commands or from a Fusion Middleware Control console. To access the keystores in any application stripe, you must have the KeyStoreAccess permission on either the entire application stripe or a particular keystore. You can be define this in the authorization policy either through WLST or Fusion Middleware Control (System-jazn-data.xml).

Note:

The stripe for B2B should be B2B. By default, this stripe is not available in KSS. You need to first create the stripe and then create corresponding keystores under this stripe.

You should use this stripe, which you create in the format: kss://<keystore-stripe>/<keystore-name>

You should use this as all keystores under B2B stripe are provided with necessary permission to use. For B2B, the uri typically resembles: kss://B2B/Acme

18.2.5.1 Using Another Stripe

If you want to use any other stripe, then while creating the key store you must perform additional steps to provide code source permission as shown in Figure 18-1 and described below.

Figure 18-1 Using Another Stripe

Description of "Figure 18-1 Using Another Stripe"

Note that you must specify:

• Grant Permission = checkbox On

• The Code Base URL = $MW_HOME/soa/modules/oracle.soa.b2b_11.1.1/b2b.jar (that is, the absolute or relative path of the b2b.jar)

If the keystore location already exists, then you must configure system policies to provide necessary privileges within system policies (e.g refer system policies chapter in opss).

For more information, see "Managing Keys and Certificates with the Keystore Service" in Oracle® Fusion Middleware Securing Applications with Oracle Platform Security Services and for using another stripe, see 'Developing with the Keystore Service" in the same volume.

18.2.5.2 Features of FKS

FKS provides the following services:

• Support for Provider Types

• Support for Keystore Type

• Support for Governance policy

• Support for certificate expiration

Provider Types

KSS supports provider-based architecture like other OPSS services. By default, the configuration for these services is available on a file-based provider. KSS also supports LDAP-based providers as supported by other OPSS services. You need to set these configuration parameters in jps-config.xml located under $DOMAIN_HOME/config/fmwconfig.

Keystore Type

A parameter indicating the type of keystore being used in KSS needs to be set in the jps-config.xml file. This is required by the runtime provider.

<property name=" kss.type" value=" KSS" />

Governance Policy

Governance policy determines what types of certificates, keys, and so on are allowed in KSS. For example, an administrator can define rules that allow only keys that are 1024 bits and higher, disallow MD5 hash algorithm, allow only RSA signing algorithm, or have key validity of at least 2 years from current time.

All these parameters are configurable in jps-config.xml as the following:

<property name=" kss.min.keysize" value=" 1024" />
<property name=" kss.disallowed.algorithms.hashing" value=" MD5" />
<property name=" kss.disallowed.algorithms.signing" value=" DSA" />
<property name=" kss.allowed.keyusage" value=" digsig,crlsign" />

Certificate Expiration

KSS provides a mechanism to configure policies to manage certificate expiration alert. It is integrated with User Messaging Service (UMS) to provide notifications and alerts.

Policy: KSS allows administrators to configure that an alert needs to be sent a specific number of days before a certificate expires. You can configure it in jps-config.xml as:

<property name=" kss.daysbefore.cert.expiration" value=" 60" />

Alerts: KSS allows administrators to configure channels to manage alerts and notifications for certificate expiration. By default, a channel is configured to log warning message to a log file. An administrator can additionally configure alerts through e-mail, SMS, and so on. Oracle B2B supports the alert mechanisms supported by UMS.You can configure multiple channels for KSS, and it is possible to specify more than one to be used for sending alerts. You can configure it in jps-config.xml as:

<property name=" kss.channel.log" value=" /tmp/alert.log" />
<property name=" kss.channel.email" value=" [e-mail],smtp.foo.com" />
<property name=" kss.channel.cell" value=" 16505067000,mobilegateway.foo.com" />
<property name=" kss.alert.channel" value=" kss.channel.log, kss. channel.email" />

Using KSS, the following keystore service operations are possible:

• Create keystore

• Delete keystore

• Update keystore

• Change keystore password

• Change key password

• Export keystore

• Import keystore

• Migrate Keystore in

• Migrate keystore out

• Validate Certificate

• Merge Certificate

18.2.5.3 Naming Convention for Keystores

Adhere to the following naming conventions for KSS keystores:

• Do not use a name longer than 256 characters.

• Do not use any of the following characters in a keystore name:

  | ; , ! @ # $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^ space tab
  

• Do not use non-ASCII characters in a keystore name.

• Additionally, follow the operating-system-specific rules for directory and file names.

18.2.5.4 Setting Up Keystore for Oracle B2B

You can set up KSS keystores for Oracle B2B either by using the Fusion Middleware Control console or by using WLST commands.

Setting Up Keystore by Using Fusion Middleware Control Console

See "Managing Keystores with Fusion Middleware Control" in Securing Applications with Oracle Platform Security Services for more information on setting up keystores.

Setting Up Keystore by Using WLST

Perform the following steps to set up the keystore for Oracle B2B using WLST commands:

1. Start Oracle Weblogic servers (Admin server and managed servers).

2. On a console window, run the following commands:

   1. cd $FMW_HOME/oracle_common/common/bin

   2. ./wlst.sh

      The preceding command sets the WLST environment.

   3. connect("<Admin user>","<Admin user password>","t3://localhost:<Admin server port>")

      The preceding command connects to the online server.

   4. svc = getOpssService(name='KeyStoreService')

      The preceding command initializes and retrieves all the keystore services.

   5. svc.createKeyStore(appStripe='<StripeName>', name='<Keystorename>', password='<keystorePassword_Optional>', permission=true/false)

      The preceding command creates the keystore. For example:

      svc.createKeyStore(appStripe='B2B', name='B2BKeyStore', password='weblogic1', permission=false)
      

   6. svc.generateKeyPair(appStripe='<StripeName>', name='<Keystorename>', password='<keystorePassword_Optional>', dn='cn=www.abc.com', keysize='1024', alias='<keyAlias>', keypassword='<KeyPassword>')

      The preceding command generates a private/public key pair with key alias <keyAlias> under the <Keystorename> store of the <StripeName> stripe.

      For example:

      svc.generateKeyPair(appStripe='B2B', name='B2BKeyStore', password='<keystorePassword_Optional>', dn='cn=www.abc.com', 
      keysize='1024', alias='Acme', keypassword='<KeyPassword>')
      

Note:

Permission for code source for b2b.jar is applicable only to the keystore under stripe B2B. By default, Oracle B2B has provisioned with code source permission for all stripes under Oracle B2B.

In the Oracle B2B console under the host trading partner Profile tab, you can specify the keystore credentials, such as Password and Location/Name as shown in Figure 18-2:

Figure 18-2 Providing Keystore Credentials

Description of "Figure 18-2 Providing Keystore Credentials"

When the trustStore is specified in the JRE, B2B uses that trustStore for establishing TLS connections. You therefore have the option to use the default .jks file that is installed with WLS or the .jks file specified by the —Djavax.net.ssl.trustStore parameter in the WLS startup script. If the b2b.httpsTrustStore server property is set to true, or it is running in a Fusion Application environment, then B2B uses the default .jks file to send for the https delivery channel.

Note:

If the keystore credentials are not provided, then the default KSS weblogic keystore is used.

18.2.6 Managing Auditing

Oracle B2B uses the OPSS audit framework to perform auditing.

See Managing Auditing in Securing Applications with Oracle Platform Security Services for more information.