In this post I'll be addressing some common security configurations and practices with respect to Oracle Documaker Enterprise Edition implementation. Questions and comments are welcome!
Documaker Enterprise Edition uses web application server
security frameworks for authentication and authorization of users. The web
application servers typically utilize frameworks that include support for
external user and group repositories that can be accessed via industry-standard
protocols, such as LDAP. The ODEE
installation process includes the deployment of a user and group data store
that works with the demonstration library.
A key component of the Documaker security model includes the
definition of entities and ability sets. An ability set is a
collection of application-specific functions with attributes that describe the
level of user exposure. An entity is an element defined in a user/group
repository – typically a group. Documaker Administrator is
used to define ability sets and to correlate them to entities, which are then
used by Documaker applications for controlling access and the user interface.
There must be at least one user and one group –
Documaker and Documaker Administrators respectively – in
order for the Documaker applications to work properly. The names of these
entities can be changed during installation or prior to startup of the system
for the first time. When connecting
Documaker to an enterprise user/group data store, ensure that there is a
Documaker Administrators group that has at least one user. If the name of this
group has been changed in the database script that creates entity entries, this
change must be reflected in the user/group data store as well. Note that a part
of the installation, it is required to run the JPSQUERY tool to link up the
user/group defined in the database script and the entities created in the
user/group data store. This step only needs to be executed once during
installation.
Upon installation, Documaker Enterprise Edition sets up a
localized security realm within the
web application server. The localized security realm is useful for several
reasons: 1) it provides a way to verify the functionality of the installation;
2) it isolates the installation from issues connecting to external services;
and 3) quicker installation for implementations that do not require external
user/group data stores. If requirements dictate the need to use an external
user/group data store, this configuration will need to happen within the web
application server.
To configure WebLogic for external user/group data stores,
you will need access to the Documaker domain within the WebLogic web console.
Note that it is possible to complete this configuration using WSLT –
see online documentation
to do this.
WebLogic Server includes the following Authentication providers:
Each LDAP Authentication provider stores user and group
information in an external LDAP
server. WebLogic Server does not support or certify any particular LDAP
servers. Any LDAP v2 or v3 compliant LDAP server should work with WebLogic
Server. The following LDAP directory servers have been tested:
Note: if your configuration has only one configured
Authentication provider for the security realm used by Documaker, then the user
that is configured for starting WebLogic Server (the “boot
user”)
must meet the following requirements:
By default the Admin role is granted to the Administrators
group so you may create this group in the LDAP directory if it does not exist.
If you wish to use a different group, include the WebLogic Server boot user in
the group and grant the Admin role to the group.
Task 1: Create
Provider instance
1. Open the WebLogic Server console for the
Documaker AdminServer and click on Security Realms.
2. Click on myrealm.
3. Click the Providers tab.
4. Click the New button.
5. Name the provider
6. Select the provider type from the dropdown.
Task 2: Set
Provider-Specific Attributes
Once the provider has been created, you can click on the new
provider and configure its provider-specific attributes on the
Provider-Specific tab. The attributes allow you to:
Here are basic settings that will work with most LDAP providers (e.g. Active Directory, or Oracle Internet Directory):
Note:
If the LDAP Authentication provider fails to connect to the
LDAP server, or throws an exception, check the configuration of the LDAP
Authentication provider to make sure it matches the corresponding settings in
the LDAP server.
Task 3: Enable SSL
for LDAP
1. Ensure that the SSLEnabled attribute for your
LDAP Authentication provider is set (as instructed in Task 2).
2. Obtain the root certificate authority (CA)
certificate for the LDAP server and create a trust keystore[1] with it.
You can do this with Java’s keytool command – an example is shown
below. Values in italics should be replaced with appropriate values for your
organization:
keytool
-import -keystore ./ldapTrustKS
-trustcacerts -alias oidtrust -file rootca.pem
-storepass TrustKeystorePwd –noprompt
3. Copy the keystore to a location accessible to
WebLogic server.
4. Start the WebLogic Server administration console
and go to idocumaker_domain à Environment à
Servers à
AdminServer à
Keystores
5. If necessary, in the Keystores field, click
Change to select the Custom Identity and Custom Trust configuration rules.
6. If the communication with the LDAP server uses
2-way SSL, configure the custom identity keystore, keystore type, and
passphrase.
7. In Custom Trust Keystore, enter the path and
file name of the trust keystore created in step 2.
8. In Custom Trust Keystore Type, enter jks.
9. In Custom Trust Keystore Passphrase, enter the
password used when creating the keystore.
10. Reboot the
WebLogic Server instance for changes to take effect.
It is a good practice to configure the LDAP provider to work
with multiple LDAP servers and enable failover if one LDAP server is not
available. Use the Host attribute (found in the Administration Console on the
Configuration à
Provider Specific page for the LDAP Authentication provider) to specify the
names of the additional LDAP servers. Each host name may include a trailing
space character and a port number. In addition, set the Parallel Connect Delay
and Connection Timeout attributes for the LDAP Authentication provider:
Hardening is the act of applying security to each component of
the infrastructure, including:
The hardening process described in this document is intended to
serve as a reminder to implement hardening for each of these elements and is
not a comprehensive hardening plan. The points contained herein will be
specific to the applications and components commonly used in a Documaker
implementation – specifically application servers and
databases. Use enterprise standards and industry best practices –
a typical practice is to begin with everything locked down and then open up
ports and access rights as necessary.
Oracle WebLogic Server uses a more specific type of
hardening known as lockdown, which refers to securing the subsystems and
applications that run on a server instance. In contrast, hardening is more
general and involves doing a security survey to determine the threat model that
may impact your site, and identifying all aspects of your environment (such as
components in the Web tier) that could be insecure. The following aspects of
WebLogic Server should be considered for lockdown:
Open the WebLogic Server administrator console to administer
roles and policies. You can create roles and policies at a global level or from
the context of an item you wish to secure.
1. In the left pane of the Administration Console,
select Security Realms.
2. On the Summary of Security Realms page, select
the name of the realm in which you want to create the role (for example,
myrealm).
3. On the Settings page, select the Roles and
Policies tab. Then select the Roles subtab. The Roles page organizes all of the
domain's resources and corresponding roles in a hierarchical tree control.
Navigate to the resource you wish to secure, and select it. This example will
illustrate creating a global role.
4. In the Roles table, in the Name column, expand
the Global Roles node.
5. In the Name column, select the name of the Roles
node.
6. In the Global Roles table click New.
7. On the Create a New Role page enter the name of
the global role in the Name field. Note: Do not use blank spaces, commas,
hyphens, or any characters in the following comma-separated list: \t, <
>, #, |, &, ~, ?, ( ), { }. Security role names are case sensitive. All
security role names are singular and the first letter is capitalized, according
to convention. The proper syntax for a security role name is as defined for an Nmtoken in the Extensible Markup Language
(XML) Recommendation[3].
8. If you have more than one role mapper configured
for the realm, from the Provider Name list select the role mapper you want to
use for this role. Role mapping is the process whereby principals (users or
groups) are dynamically mapped to security roles at runtime. The role mapper provider
is responsible for saving your role definition in its repository. See Configure
Role Mapping providers[4].
9. Click OK to save your changes.
10. In the
Global Roles table select the role.
11. In the
Role Conditions section click Add Conditions.
12. On the
Choose a Predicate page, in the Predicate List, select a condition. Oracle
recommends that you use the Group condition whenever possible. This condition
grants the security role to all members of the specified group (that is,
multiple users). For a description of all conditions in the
Predicate List, see Security Role Conditions.
13.The
next steps depend on the condition that you chose:
14. If you
selected Group or User, click Next, enter a user or group name in the argument
field, and click Add. The names you add must match groups or users in the security
realm active for this WebLogic domain.
15. If you
selected a boolean predicate (Server is in development mode , Allow access to
everyone, or Deny access to everyone) there are no arguments to enter. Click
Finish and go to step 15.
16. If you
selected a context predicate, such as Context element's name equals a numeric
constant, click Next and enter the context name and an appropriate value. It is
your responsibility to ensure that the context name and/or value exists at
runtime.
17. If you
selected a time-constrained predicate, such as Access occurs between specified
hours, click Next and provide values for the Edit Arguments fields.
18.Click
Finish.
19. (Optional)
Create additional role conditions.
20. (Optional)
The WebLogic Security Service evaluates conditions in the order they appear in
the list. To change the order, select the check box next to a condition and
click the Move Up or Move Down button.
21. (Optional)
Use other buttons in the Role Conditions section to specify relationships
between the conditions:
22. Select
And/Or between expressions to switch the and / or statements.
23.Click
Combine or Uncombine to merge or unmerge selected expressions. See Combine Conditions.
24. Click
Negate to make a condition negative; for example, NOT Group Operators excludes
the Operators group from the role.
25. Click
Save.
The web application servers that implement the Web
Service-Security (WS-S) standards secure Documaker Web Services (DWS). Both
WebLogic and WebSphere provide standard WS-S implementations that allow for the
definition of security policies including access and authorization for web
service consumption. Ensure DWS is configured with appropriate policies and
roles to prevent unauthorized consumption of web services.
It is important to note that the encryption used by SSL is
"all or nothing": either the entire SOAP message is encrypted or it
is not encrypted at all. There is no way to specify that only selected parts of
the SOAP message be encrypted.
The best practice for securing web services for Documaker in
environments requiring higher levels of security is to implement the following
measures with WebLogic Server. Note that the last item, access-control
security, is only required if corporate security policy dictates that access to
web services should be restricted.
Message-level security specifies whether the SOAP messages
between a client application and the Web service invoked by the client should
be digitally signed or encrypted, or both. It also can specify a shared security
context between the Web service and client in the event that they exchange
multiple SOAP messages. You can use message-level security to assure:
Supported use cases for this level of security:
A Web service can have zero or more WS-Policy files associated
with it. WS-Policy files follow the guidelines of the WS-Policy specification. WebLogic
Server uses WS-Policy files to specify the details of the message-level
security (digital signatures and encryption) and reliable messaging
capabilities of a Web service. You can attach a WS-Policy file to a Web service endpoint,
which means that the policy assertions apply to all the operations of a Web
service endpoint. You can also attach a WS-Policy file to an operation, which
means that the policy assertions apply only to the specific operation. In addition, you can attach a WS-Policy file to the inbound
or outbound SOAP message, or both. For example, if a WS-Policy file that
specifies encryption for the body of a SOAP message is attached to just the
inbound message of a particular operation, only the SOAP request needs to be
encrypted. After you have attached a WS-Policy file to a Web service
endpoint or operation, the assistant updates the application's deployment plan.
If the application does not currently have a configured deployment plan, the
assistant creates one for you in the location you specify.
Types of Policies
You can attach two types of policies to WebLogic Web
Services: Oracle Web Services Manager policy and WebLogic Web Service policy.
Pre-packaged WebLogic Web Service Policies
WebLogic Server includes pre-packaged WS-Policy files that
you can use for configuring message-level security and reliable messaging,
including the following. These files are static and you cannot change them.
Predefined policies are available in the following categories:
• Reliable
Messaging: Set of WS-Policy files that enable you to configure Web services
reliable messaging.
• SOAP
Message Transmission Optimization Mechanism (MTOM): Used to specify that
the Web service supports MTOM to transport binary data. MTOM describes a method
for optimizing the transmission of XML data of type xs:base64Binary using MIME
attachments over HTTP to carry that data while at the same time allowing both
the sender and the receiver direct access to the XML data without having to be
aware that any MIME artifacts were used to marshal the xs:base64Binary data.
• Security: Two sets of pre-packaged security policy
files are available for configuring message-level security. One set of security
policy files conforms to the OASIS WS-SecurityPolicy 1.2 specification. These
security policy files are described in Using
WS-SecurityPolicy 1.2 Policy Files in Securing Web Services for Oracle
WebLogic Server. The other set of security policy files conforms to a
proprietary Oracle Web services security policy schema and are described in Proprietary
Web Services Security Policy Files (JAX-RPC Only) in Securing Web
Services for Oracle WebLogic Server. You can use security policy files from
either set, but the two sets are not mutually compatible; you cannot define
both types of policy file in the same Web service.
Pre-packaged Oracle WSM Policies
Oracle WSM includes a set of predefined policies in the
following categories: security, WS-Addressing, MTOM, reliable messaging, and
management.
Note that the
Administration Console allows you to associate as many WS-Policy files as you
want to a Web service and its operations, even if the policy assertions in the
files contradict each other. It is up to you to ensure that multiple associated
WS-Policy files work together. If any contradictions do exist, WebLogic Server
will return a runtime error when a client application invokes the Web service.
To associate a WS-Policy file with a Web service:
You must configure SSL encryption for WebLogic Server before
continuing. You may then apply policies using the steps outlined above for
message-level security.
This level of security has specific implications for clients
wishing to consume web services; client application that invokes the Web
service must specify certain properties to indicate the SSL implementation in
use. In particular:
The following access scenarios indicate typical use cases for
the Documaker system and can be used to guide your security policy definition.
These descriptions outline the default
out-of-the-box configuration of the system.
This use case is applicable for all Documaker Web Services
(DWS) endpoints and operations.
This use case is applicable for all Documaker applications
deployed within the web application server (e.g. Documaker Dashboard, Documaker
Administrator, and Documaker Interactive).
You made it! I know that's a lot of information to digest, and hopefully it was organized in such a way as to be helpful. If you have any followup questions or comments, unleash them below!
[1] More information is available here.
[2] Applications are configured for DD-only security (deployment descriptor)
which means that if you wish to add role- and/or policy-based security on top
of this, you must modify the deployment descriptors for the affected
application(s). Keep in mind this will affect upgrade capability as you have to
re-apply deployment descriptor changes.
[3] http://www.w3.org/TR/REC-xml/#NT-Nmtoken
[4] http://docs.oracle.com/cd/E28280_01/apirefs.1111/e13952/taskhelp/security/ConfigureRoleMappingProviders.html
[5] It is possible to
utilize single sign-on features here provided the web application server
supports the desired SSO model.