Security options
This chapter gives an overview of how the Liberty JVM server implements Java Platform, Enterprise Edition security, along with the integration it provides with traditional CICS security. Throughout this chapter, we highlight and explain choices that you can make to tailor Liberty JVM security to meet your needs.
For more information about how to set up and implement CICS Liberty security, see Chapter 8, “Implementing security options” on page 143.
This chapter describes the following topics:
4.1 Java Platform, Enterprise Edition security
When you click a link to invoke a web application, what happens in CICS Liberty JVM server before that web application gets control? There is a series of steps, defined by Java Platform, Enterprise Edition specifications, which take place in the web container to ensure that the user is authorized to run the web application.
4.1.1 Deployment descriptor
The first item to understand in Java Platform, Enterprise Edition security is the web deployment descriptor. This is the web.xml file that is in the WEB-INF subdirectory of a web project. In our GenAppWeb example, its looks as shown in Example 4-1.
Example 4-1 Web deployment descriptor
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-constraint>
<display-name>Broker Role</display-name>
<web-resource-collection>
<web-resource-name>GenAppWeb</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name> Broker</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
The key items in the web.xml file in Example 4-1 are:
– Authentication method: Using the <login-config> element and its <auth-method> sub element is key to defining how a user of this web application is authenticated by the web container. If the <auth-method> element is present, the user must be authenticated to access any resource that is constrained by a <security-constraint> rule in web.xml. The three authentication method options available in Liberty are BASIC for basic authentication, FORM for form-based authentication, or CLIENT-CERT for Secure Sockets Layer (SSL) client certificates. In addition, the Java Platform, Enterprise Edition specification supports DIGEST authentication. However, this is not available in Liberty.
– URL pattern: The <url-pattern> defines the URLs in the web application to which this security constraint applies. In our example, all URLs are protected by using the /* prefix.
– Role name: The <role-name> element is the access group the server uses for authorization to this application. In this example, all users need to be in the Broker role.
– Transport guarantee: The <transport-guarantee> sub element of the <user-data-constraint> defines whether or not encryption is required when accessing this application. If CONFIDENTIAL is listed, a protected transport layer connection, such as HTTPS is required when accessing this application. This means that you would need to define a <httpEndpoint> in the server.xml configured to use an httpsPort.
|
Note: Instead of using the <role-name> element in an authorization constraint in web.xml to grant access to specific roles, it is also possible to programmatically declare which roles are authorized to access Java components. This can be done by using either annotations, such as @RolesAllowed, or the isCallerInRole() method. For more information about securing Java EE components programmatically, see the following tutorial:
|
For general details about Java EE 6 application security, refer to the Oracle Java EE 6 tutorial at:
4.1.2 Key steps in security processing
Figure 4-1 illustrates the steps in security processing of an HTTP request running in a Liberty JVM server.
The Liberty angel process is a key part of any Liberty server security infrastructure on z/OS. The angel process provides a Liberty server with access to z/OS authorized services, such as System Authorization Facility (SAF) authentication and authorization. Each Liberty server must register with the angel at startup to use authorized services. However, registration is limited to only one process per address space. This means that it is only possible to configure one Liberty JVM server per CICS region to use the function of the cicsts:security-1.0 feature.
Figure 4-1 Security processing of HTTP requests
The three steps in Liberty server security processing are as follows:
•Authentication by the web container
•Authorization by the web container
•Security processing during CICS transaction attach
4.1.3 Authenticate
The first step is authentication. Authentication is the process of finding out and verifying the identity of the user who is attempting to run the application. This function is performed entirely by the Java Platform, Enterprise Edition security feature in Liberty, by enabling the appSecurity-2.0 feature in server.xml. This step also requires access to the angel process to provide access to SAF-authorized services if an SAF registry is used as the registry type.
There are four different means by which Liberty can authenticate a user. These are:
1. Basic authentication: The simplest example is basic authentication, whereby the web container rejects the initial request with an HTTP 401 status code. This causes the browser to present a pop-up window requesting a user ID and password, which is then used by the browser to resubmit the request.
2. Form logon: In this scenario, a customized HTML form is created, which is added to the application and used to supply the user ID and password.
3. SSL client authentication: In this scenario, an SSL client certificate is mapped to a user ID in the local security registry. When this client certificate is presented, the request is authenticated by using the specified user ID.
4. Trust association interceptor (TAI): The trust association interface is a service provider API that enables the integration of third-party security services with a Liberty server. This function allows the authenticated subject to be programmatically determined for each request, providing for a simple means of identity assertion.
There are also three different registries available for verifying the user ID and password: SAF, LDAP, and a basic user registry. We discuss the advantages and disadvantages of these different methods of authentication in 4.3, “Security registries” on page 64.
If the user fails authentication, the Liberty server rejects the request. However, if the user passes authentication, a valid Java subject, containing the details of the user ID and authentication realm, is available. This is passed to the next step, authorization.
4.1.4 Authorize
The next step is authorization. At this point, we know who the user is and we have a valid user ID. Authorization determines if the authenticated user has the correct privileges to access the web application. This is determined by using roles. In our example, if the user is in the Broker role, that user is authorized to run the application. If the user is not a Broker, Liberty rejects the request.
To understand what authorization is, it is helpful to remember the security steps that happen before granting authorization:
1. A security constraint in the application web.xml file establishes the role or roles that are authorized to access a particular part of the URL path.
2. Authentication establishes the user ID that wants to access that path.
3. Authorization determines if the authenticated user ID belongs to the authorized role.
Authorization uses user role mapping to find out if a user, or group of users, belongs to a certain role. There are three options to set up this authorization in a Liberty JVM server:
1. CICS bundles and the cicsAllAuthenticated role
If you deploy a web application as a CICS bundle, you need to add the cicsAllAuthenticated role to authorization constraint in your web deployment descriptor as follows:
<auth-constraint>
<role-name> Broker</role-name>
</auth-constraint >
CICS then creates the application definition statements in the installedApps.xml server configuration file. Then, CICS grants access to this role for all authenticated users using the special subject ALL_AUTHENTICATED_USERS (meaning all users who have passed authentication).
Example 4-2 shows what the application element in server.xml looks like when GenAppWeb is deployed as a CICS bundle.
Example 4-2 GenAppWeb deployed as CICS bundle in server.xml
<application id="GenAppWeb" name="GenAppWeb" type="war"
location="${server.output.dir}/installedApps/GenAppWeb.war"
bundle="GenApp" token="22ABF9E000000100" bundlepart="GenAppWeb">
<application-bnd>
<security-role name="cicsAllAuthenticated">
<special-subject type="ALL_AUTHENTICATED_USERS"/>
</security-role>
</application-bnd>
</application>
There are two possible ways that Liberty JVM server in CICS performs authorization. One is called SAF authorization, which uses the EJBROLE classes in the SAF registry. The other is Java Platform, Enterprise Edition role authorization, which uses the roles defined in the server.xml configuration file.
Using this option requires that you have the ability to update the deployment descriptor in your web application. In addition, this option delegates request authorization to CICS transaction and resource security checking (see 4.1.5, “CICS transaction security” on page 62) as from a Java Platform, Enterprise Edition security point of view. Any authenticated user has access to run the web application. However, it is also possible to combine CICS transaction security authorization with the usage of SAF authorization using EJBROLEs (option 3., “SAF authorization” on page 62). This is because setting the <safAuthorization/> element prevents access to the cicsAllAuthenticated role being granted to ALL_AUTHENTICATED_USER. Instead, the EJBROLE permission is used.
2. Liberty security role authorization
The next option for user role mapping is to use <security-role> elements in the application definition in the server.xml or ibm-application-bnd.xml file in the enterprise archive (EAR). This method uses a definition in the application-bnd element of each application. These definitions establish which users or user groups are authorized to certain roles.
Say that the web application security constraint defines the Broker role as follows:
<role-name> Broker </role-name>
The application element might look like that shown in Example 4-3 if you wanted to grant access to the authenticated user1 and any user ID in the webusers group.
Example 4-3 Security roles defined in server.xml
<application id="GenAppWeb"
name="GenAppWeb" type="war"
location="/u/reds13/cicsts53/GenAppWebBundle_1.0.0/GenAppWeb.war">
<application-bnd>
<security-role name="Broker">
<user name="user1" />
<group name="webusers" />
</security-role>
</application-bnd>
</application>
|
Note: In a Liberty JVM server, if you want to use Java Platform, Enterprise Edition security roles without SAF authorization, you cannot use CICS bundles to install your applications, as the application-bnd element will always be created with the cicsAllAuthenticated role. However, this can be a useful method if you are porting an application directly from a third-party Java Platform, Enterprise Edition application server that uses this method.
|
3. SAF authorization
Liberty uses SAF authorization when the <safAuthorization/> element is present in server.xml, and determines the EJBROLE class to be validated using the <safRoleMapper profilePattern=…> element. Authenticated users are then authorized to access an application by giving them access to the EJBROLE referenced in the profilePattern attribute. This option requires access to the SAF authorized services using the angel process. For more information about configuring SAF authorization, see Chapter 8, “Implementing security options” on page 143.
EJBROLEs can be used with CICS bundle-deployed applications because the <application-bnd> and cicsAllAuthenticated role is ignored by Liberty in favor of using the EJBROLE mappings defined by the SAF registry.
4.1.5 CICS transaction security
The first two steps (described in 4.1.3, “Authenticate” on page 60 and 4.1.4, “Authorize” on page 60) are common to any Java Platform, Enterprise Edition application server. This third step, CICS transaction security, is unique to a Liberty JVM server in CICS TS. This is where CICS builds the transaction environment that enables the web application to run as a CICS task and invoke CICS services. As such, it is a critical point at which CICS security can be used to ensure that the user ID is authorized to run the transaction, and is implemented by using the cicsts:security-.1-0 feature, defined in server.xml.
As part of this process, two key decisions need to be made by the CICS runtime during transaction attach processing:
1. The CICS transaction ID must be chosen: The default is CJSA, but this can easily be overridden by using a URIMAP resource, which maps the URI and the protocol (HTTP or HTTPS) to a specified CICS transaction ID.
2. The CICS task user ID must be set: The user ID is taken from the authenticated Java subject and used to set the CICS transaction security context during transaction attach processing. In doing so, the user ID needs read access to the SAF resource group (TCICSTRN) for the CICS transaction chosen at Step 1. If the user ID does not have access to this profile, the request is rejected.
The result of this process gives you the following security choices:
1. If there is an authenticated SAF user ID from the Java subject, this is used to run the CICS transaction. This should always be the case if there is a security constraint in the web.xml file.
2. If there is no authenticated user ID, the USERID specified on the URIMAP definition is used to run the CICS transaction. This is the case, for instance, if there was no security constraint in the web.xml file.
3. If there is no USERID on the URIMAP definition and no authenticated user ID, the default user ID for that CICS region is used to run the transaction. This is a default setup, and it is unlikely that the default user should be granted access in this scenario in a secure system.
4.2 Confidentiality
You can configure a Liberty JVM server to use SSL for data encryption, and optionally authenticate with the server by using a client certificate. Certificates can be stored in a Java keystore held on the zFS filing system or in a SAF key ring such as IBM RACF®.
If the security constraint in the web.xml file defines a transport-guarantee of CONFIDENTIAL, all communication with this web application needs to be using an HTTPS-enabled endpoint. See Example 4-4.
Example 4-4 Excerpt from web.xml
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
To make an environment secure, you must be sure that any communication is with trusted sites whose identity you can be sure of. SSL uses certificates for authentication. These are digitally signed documents, which bind the public key to the identity of the private key owner:
•SSL client authentication
The process of SSL client authentication occurs when the underlying socket is first established. Authentication is performed by an exchange of certificates in X.509 format between the client and the server. A Liberty server allows you to specify that client authentication is required for connections to a particular HTTP endpoint by adding the clientAuthentication="true" attribute to the SSL configuration element in server.xml.
In addition, if you want requests to run under the identity of the user ID to which the personal certificates are mapped in the keystore, you can specify the value CLIENT-CERT on the auth-method element in the web.xml deployment descriptor, as shown in Example 4-5.
Example 4-5 Excerpt from web.xml
<login-config>
<auth-method>BASIC </auth-method>
</login-config>
As extra protection, it is also possible to request Liberty to drive an HTTP basic authentication challenge if the CLIENT-CERT identity is not authorized to the application. This is achieved by adding the following webAppSecurity element to server.xml.
<webAppSecurity allowFailOverToBasicAuth="true" />
4.3 Security registries
Liberty provides a choice of security registries, which can be used to authenticate users accessing protected web applications.
4.3.1 Basic user registry
The basic user registry is part of the appSecurity-2.0 feature and provides a simple, text-based registry in the server.xml file. This can be found by using the basicRegistry element shown in Example 4-6.
Example 4-6 Basic user registry definition in server.xml
<basicRegistry id="basic" realm="customRealm">
<user name="dan" password="p@ssw0rd" />
<user name="andy" password="pa$$w0rd" />
<user name="shayla" password="pa$$w0rd" />
<user name="indi" password="{xor}Lz4sLCgwLTs=" />
<group name="residents">
<member name="dan" />
<member name="andy" />
</group>
</basicRegistry>
Because access to server.xml is not controlled by SAF, and because this registry is not integrated with CICS Liberty security or synchronized with SAF, it is not advisable to use this registry type for any purpose other than testing.
4.3.2 System Authorization Facility
Integration with an SAF user registry, such as RACF, is part of the Liberty zosSecurity-1.0 feature, which is integrated into the CICS Liberty security feature (cicsts:security-1.0). All of the supported Java Platform, Enterprise Edition authentication mechanisms, including basic authentication, form-based authentication, and SSL client authentication, can use an SAF registry to authenticate users. In addition, the EJBROLE support in Liberty can use the SAF registry to authorize access to the roles defined in web.xml, and CICS transaction and resource security can use SAF to authorize access to CICS resources.
4.3.3 LDAP and distributed identities
Many Java Platform, Enterprise Edition application servers on distributed platforms, such as WebSphere Application Server, support the use of an LDAP security registry to authenticate users. Liberty on z/OS also supports this ability. However, it also supports a means to map these distributed identities in X.509 form to RACF user IDs that use mapping known as distributed identity filters. These filters describe the mapping association between a RACF user ID and one or more distributed identities.
Example 4-7 shows a RACMAP. This maps the LDAP user with the X.509 distinguished name ‘CN=Alice,OU=ITSO,O=IBM,C=US’ to the RACF user ID ALICE.
Example 4-7 RACMAP example
RACMAP ID(ALICE)
USERDIDFILTER(NAME(‘CN=Alice,OU=ITSO,O=IBM,C=US’))
REGISTRY(NAME(‘ldaps://itso.ibm.com’))
WITHLABEL(‘Alice’)
This function is supported in CICS TS V5.3 by using the new cicsts:distributedIdentity-1.0 feature. It can be used with the cicsts:security-1.0 feature to take the RACF user ID from the mapping, then set this as the CICS transaction security context. This allows EJBROLEs and CICS transaction security to be used for authorization and an LDAP registry to be used for Java Platform, Enterprise Edition authentication.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.