Technical info and insight on using Oracle Documaker for customer communication and document automation
-
ODEE
December 17, 2015
Security with Documaker Enterprise
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!
Users and Groups
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.
Configuring WebLogic for External User/Group Data Store
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:
- Oracle Internet Directory Authentication
provider - Oracle Virtual Directory Authentication provider
- iPlanet Authentication provider
- Active Directory Authentication provider
- Open LDAP Authentication provider
- Novell Authentication provider
- generic LDAP Authentication provider
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:
- Oracle Internet Directory
- Oracle Virtual Directory
- Sun iPlanet version 4.1.3
- Active Directory shipped as part of Windows 2000
- Open LDAP version 2.0.7
- Novell NDS version 8.5.1
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:
- Exist in the LDAP directory
- Be a member of a group that has the Admin role
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:
- Enable communication between the LDAP server and
the LDAP Authentication provider. For a more secure deployment, Oracle recommends
using the SSL protocol to protect communications between the LDAP server and
WebLogic Server. Enable SSL with the SSLEnabled attribute. - Configure options that control how the LDAP
Authentication provider searches the LDAP directory. - Specify where in the LDAP directory structure
users are located. - Specify where in the LDAP directory structure
groups are located. - Define how members of a group are located.
- Set the name of the global universal identifier
(GUID) attribute defined in the LDAP server. - Set a timeout value for the connection to the
LDAP server. The LDAPServerMBean.ConnectTimeout attribute for all LDAP
Authentication providers has a default value of zero. This default setting can
result in a slowdown in WebLogic Server execution if the LDAP server is
unavailable. Oracle recommends that you set the
LDAPServerMBean.ConnectTimeout attribute to a non-zero value (e.g. 60 seconds). - Configure performance options that control the
cache for the LDAP server. Use the Configuration > Provider Specific and
Performance pages for the provider in the Administration Console to configure
the cache. See Improving the Performance of
WebLogic and LDAP Authentication Providers.
Here are basic settings that will work with most LDAP providers (e.g. Active Directory, or Oracle Internet Directory):
- Login to WebLogic console
- Click on Security Realms, and select "myrealm"
- Navigate to Providers > Authentication and click New.
- Name your provider something memorable, like "Andy's Authenticator" or perhaps something technical, like "SuperCoOID".
- Select the type of the authenticator. For Active Directory, select "LDAP Authenticator". For Oracle Internet Directory, select "OracleInternetDirectoryAuthenticator".
- Click OK.
- Click on the authenticator you just created, and you're on the Common configuration tab.
- Set the Control Flag to SUFFICIENT.
- Click Save.
- Click on the Provider Specific tab. You may need your LDAP repository administrator to help you with these values.
- Set the Host and Port values.
- Set the Principal and Credential values (this is the login information to the LDAP provider, e.g. Principal = "cn=admin", Credential is the password).
- Set the User Base DN. This identifies the users(s) that will be available to the application, e.g. "cn=Users, dc=mysubdomain, dc=oracle, dc=com".
- Ensure the "Use Retrieved User Name as Principal" checkbox is checked.
- Set the Group Base DN. This identifies the group(s) that will be available to the application, e.g. "cn=DocumakerGroup, dc=mysubdomain,dc=oracle,dc=com".
- Click Save.
- Go back to the Authentication tab, and click Reorder. Move your new Authenticator to the top of the list. Save.
- Restart your AdminServer (you will need to shutdown your managed servers, and any services like Documaker Factory and Docupresentment as well).
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.
Tuning WebLogic LDAP Provider for High Availability
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:
- Parallel Connect Delay—Specifies
the number of seconds to delay when making concurrent attempts to connect to
multiple servers. An attempt is made to connect to the first server in the
list. The next entry in the list is tried only if the attempt to connect to the
current host fails. This setting might cause your application to block for an
unacceptably long time if a host is down. If the value is greater than 0,
another connection setup thread is started after the specified number of delay
seconds has passed. If the value is 0, connection attempts are serialized. - Connection Timeout—Specifies the maximum
number of seconds to wait for the connection to the LDAP server to be
established. If the set to 0, there is no maximum time limit and WebLogic
Server waits until the TCP/IP layer times out to return a connection failure.
Set to a value over 60 seconds depending upon the configuration of TCP/IP.
Hardening
Hardening is the act of applying security to each component of
the infrastructure, including:
- Web Servers
- Application Servers
- Identity and Access Management solutions
- Database systems
- Operating systems
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.
WebLogic Server
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:
- SSL-enabling components and component routes
- Documaker
web applications install with SSL enabled. - LDAP
Authentication providers should be configured for SSL - Configure
two-way SSL - one-way SSL is a configuration where clients request a server
certificate and the server accepts all connections. Two-way SSL configurations
require the client and the server to exchange certificates, thereby providing
an additional layer of trust by ensuring that non-trusted clients cannot invoke
services. - SSL-enabling web services - Documaker
Web Services install with SSL disabled and should be enabled. - Managing ports and other features of the site
such as: - default
deployed application – remove any non-essential default apps such as
the welcome page - demonstration/samples
–
remove demoApp, demo keystores, demo trust, and demo SSL certificate - change
default ports for common services e.g. admin port –
Documaker services ship with standard ports; however, these are not common and
could remain as-is. The base WebLogic components (e.g. console) are configured standard
ports and should be changed from the default (7001). - Password management
- Roles and Policies for access –
role- and policy-based security should be configured for authorized access to: - web
services - data
sources - applications[2] –
note that Documaker applications feature separate access controls set in the
Documaker Administrator (Entities and Ability Sets); however this configuration
can provide an additional layer of security if needed.
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.
Web Service Security
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.
Securing Web Services with WebLogic
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 – Data
in a SOAP message is digitally signed or encrypted. May also include identity
tokens for authentication. This security level includes all the security
benefits of SSL, but with additional flexibility and features. Message-level
security is end-to-end, which means that a SOAP message is secure even when the
transmission involves one or more intermediaries. The SOAP message itself is
digitally signed and encrypted, rather than just the connection. And finally,
you can specify that only individual parts or elements of the message be
signed, encrypted, or required. - Transport-level security – SSL
is used to secure the connection between a client application and WebLogic
Server with Secure Sockets Layer (SSL). SSL provides secure connections by
allowing two applications connecting over a network to authenticate the other's
identity and by encrypting the data exchanged between the applications.
Authentication allows a server, and optionally a client, to verify the identity
of the application on the other end of a network connection. A client
certificate (two-way SSL) can be used to authenticate the user. Encryption
makes data transmitted over the network intelligible only to the intended
recipient. Transport-level security includes HTTP BASIC authentication as well
as SSL. Transport-level security, however, secures only the connection itself.
This means that if there is an intermediary between the client and WebLogic
Server, such as a router or message queue, the intermediary gets the SOAP
message in plain text. When the intermediary sends the message to a second
receiver, the second receiver does not know who the original sender was.
Additionally, 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. - Access control security – Specifies
which roles are allowed to access Web services. This answers the question
"who can do what?" First you specify the security roles that are
allowed to access a Web service; a security role is a privilege granted
to users or groups based on specific conditions. Then, when a client
application attempts to invoke a Web service operation, the client
authenticates itself to WebLogic Server, and if the client has the
authorization, it is allowed to continue with the invocation. Access control
security secures only WebLogic Server resources. That is, if you configure only
access control security, the connection between the client application and
WebLogic Server is not secure and the SOAP message is in plain text.
Implementing Message-level security
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:
- Confidentiality, by encrypting message parts
- Integrity, by digital signatures
- Authentication, by requiring username, X.509, or
SAML tokens
Supported use cases for this level of security:
- Use X.509 certificates to sign and encrypt a
SOAP message, starting from the client application that invokes the
message-secured Web service, to the WebLogic Server instance that is hosting
the Web service and back to the client application. - Specify the SOAP message targets that are
signed, encrypted, or required: the body, specific SOAP headers, or specific
elements. - Include a token (username, SAML, or X.509) in
the SOAP message for authentication. - Specify that a Web service and its client
(either another Web service or a standalone application) establish and share a
security context when exchanging multiple messages using WS-SecureConversation
(WSSC). - Derive keys for each key usage in a secure
context, once the context has been established and is being shared between a
Web service and its client. This means that a particular SOAP message uses two
derived keys, one for signing and another for encrypting, and each SOAP message
uses a different pair of derived keys from other SOAP messages. Because each
SOAP message uses its own pair of derived keys, the message exchange between
the client and Web service is extremely secure.
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:
- In the left pane of the
Administration Console, select Deployments. - In the right pane,
navigate within the Deployments table until you find the Web
service for which you want to configure a WS-Policy file. Note: Web
services are deployed as part of an Enterprise application, Web
application, or EJB. To understand how Web services are displayed in the
Administration Console, see View
installed Web services. - In the Deployments
table, click the name of the Web service. - Select Configuration
-> WS-Policy. The table lists the WS-Policy files that are
currently associated with the Web service. The top level lists all the
ports of the Web service. Click the + next to a Web service port to see
its operations and associated WS-Policy files. - To associate a WS-Policy
file with an entire Web service endpoint (port): - Click the name of the
Web service port. A page appears which includes two columns: one labelledAvailable Endpoint Policies that lists the names of the WS-Policy
files that you can attach to a Web service endpoint and one labelled Chosen
Endpoint Policies that lists the WS-Policy files that are currently
configured for this endpoint. - Use the arrows to move
WS-Policy files between the available and chosen columns. The WS-Policy
files that are in the Chosen column are attached to the Web service
endpoint. - Click OK. If your
Web service already has a deployment plan associated to it, then the
newly attached WS-Policy files are displayed in the Policies
column in the table. If the J2EE module
of which the Web service is a part does not currently have a deployment
plan associated with it, the assistant asks you for the directory that
should contain the deployment plan. Use the navigation tree to specify a
directory, then click Finish. - To associate a WS-Policy
file with a Web service operation: - Click the name of the
operation. A page appears which includes two columns: one labeled Available
Message Policies that lists the names of the WS-Policy files that are
available to attach to the inbound (request) and outbound (response) SOAP
message of the operation invoke and one labeled Chosen Message
Policies that lists the WS-Policy files that are currently attached
to the inbound and outbound SOAP message of the operation invoke. - Use the arrows to move
WS-Policy files between the available and chosen columns. The WS-Policy
files that are in the Chosen column are the ones that are attached to the
inbound and outbound SOAP message when this operation is invoked by a
client application. - Click Next.
- A page appears which
includes two columns: one labeled Available Inbound Message Policies
that lists the names of the WS-Policy files that are available to attach
to the inbound (request) SOAP message of the operation invoke and one
labeled Chosen Outbound Message Policies that lists the WS-Policy
files that are currently attached to the inbound SOAP message of the
operation invoke. - Use the arrows to move
WS-Policy files between the available and chosen columns. The WS-Policy
files that are in the Chosen column are the ones that are attached to the
inbound (request) SOAP message when this operation is invoked by a client
application. - Click Next.
- A page appears which
includes two columns: one labeled Available Outbound Message Policies
that lists the names of the WS-Policy files that are available to attach
to the outbound (response) SOAP message of the operation invoke and one
labeled Chosen Outbound Message Policies that lists the WS-Policy
files that are currently attached to the outbound SOAP message of the
operation invoke. - Use the arrows to move
WS-Policy files between the available and chosen columns. The WS-Policy
files that are in the Chosen column are the ones that are attached to the
outbound (response) SOAP message when this operation is invoked by a
client application. - Click Finish. If your Web service already
has a deployment plan associated with it, the attached WS-Policy files are
displayed in the Policies column in the table. If the
J2EE module of which the Web service is a part does not currently have a
deployment plan associated with it, the assistant asks you for the directory
that should contain the deployment plan. Use the navigation tree to specify a
directory, then click Finish.
Implementing Transport-Level Security
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:
- To specify the Certicom SSL implementation, use
the following properties - -Djava.protocol.handler.pkgs=weblogic.net
- -Dweblogic.security.SSL.trustedCAKeyStore=trustStore
- Where trustStore
specifies the name of the client-side truststore that contains the list of
trusted certificates (one of which should be the server's certificate). To
disable host name verification, also specify the following property: - -Dweblogic.security.SSL.ignoreHostnameVerification=true
- To specify the Sun SSL implementation, use the
following properties: - -Djavax.net.ssl.trustStore=trustStore
- Where trustStore
specifies the name of the client-side truststore that contains the list of
trusted certificates (one of which should be the server's certificate). To
disable host name verification, also specify the following property: - -Dweblogic.wsee.client.ssl.stricthostchecking=false
Access Scenarios
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.
Web Services for Document Generation
This use case is applicable for all Documaker Web Services
(DWS) endpoints and operations.
- A client application that wants to consume a DWS
operation establishes a connection to the appropriate endpoint. - Additional security policies can be applied at
the web application server level to further secure the web service, such as: - Transport-level
security, providing SSL encryption of the message. - Message-level
security, which encrypts the contents of the message - Access-level
control, which uses policies to grant or deny access to the web service.
Interactive User Document Editing
This use case is applicable for all Documaker applications
deployed within the web application server (e.g. Documaker Dashboard, Documaker
Administrator, and Documaker Interactive).
- A user opens a web browser and accesses the URL
for a Documaker application - A secure connection is established according to
the deployment descriptor for the Documaker application: the client browser
requests a server certificate, which is sent and validated. - Additional security policies can be applied at
the web application server level to further secure the web application (e.g.
policy-based security). - The Documaker application requests the user’s
login credentials via a login dialog[5]. - The Documaker application relies on the web
application server to authenticate the credential against the security store. - Upon successful authentication, the Documaker
application caches (or updates the cache) with the user’s
group membership. - The Documaker application then compares the
group member to the entities defined within the configuration tables and
determines the application-specific ability sets allocated to those entities. - The Documaker application then renders the user
interface according to the ability sets afforded to the user based on their
group membership.
Conclusion
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!
Footnotes
[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.