Introduction
This is part of the Heirloom Computing Elastic Batch Platform forum on paas.heirloomcomputing.com. The document concerns the Heirloom Computing Resource Access Control (RAC) security mechanism in both Elastic Batch Platform (EBP) and the Elastic Transaction Platform (ETP).
There are four areas of security that will be addressed in this article:
- Transport Level Security - ensuring data between EBP and/or ETP and the clients is secure
- Platform Security - ensuring the platform on which EBP and/or ETP is running is secure
- Authentication - validating who can use EBP and/or ETP
- Authorization - indicating who can use what services against which objects
For the latter two areas you must make some decisions as to how to "lock down" your EBP and/or ETP system and which users are allowed to submit jobs, access datasets, etc.
| None | No configuration | No protection | None |
| Partial with files | J2EE server performs text file-based configuration, EBP/ETP does no A&A | No authorization | J2EE server memory mode configuration |
| Partial with directory server | J2EE Server performs password checking against a JNDI directory Server, EBP does not see passwords | No authorization, container configuration and LDAP server setup required | J2EE JNDI Realm security |
| Full | Full A&A, EBP/ETP performs password checking against an LDAP directory server such as Microsoft Active Directory or OpenLDAP or Apache Directory Server | Configuration to EBP/ETP, container and LDAP server |
J2EE JAAS Realm security Heirloom Computing RAC |
Authorization and Authentication in EBP/ETP is provided by the Heirloom Computing Resource Access Control (RAC) module. By default no security is turned on. You can configure the built in RAC module which uses an LDAP directory server to check security or construct your own custom RAC. See Creating your own RAC later in this document. If configured to use the default RAC module and an LDAP directory server is available to check against, EBP and ETP will attempt to authorize resources against it. LDAP entries for users and resources must then be defined or all EBP/ETP operations (job submittal, dataset access) will be denied to all users. See the Authentication and Authorization sections regarding configuration.
Transport Level Security
It is recommended that EBP/ETP be deployed to servlet containers that support SSL such that all data is encrypted between the client and Web services. In the Heirloom Platform-as-a-Service available at paas.heirloomcomputing.com SSL encryption for all servers (Apache Tomcat, Apache HTTPD is provided by stunnel and server certificates are defined only to it. But, all J2EE servers (IBM Websphere, Oracle Weblogic, Red Hat JBOSS / Wildfly) and Servlet Containers (Apache Tomcat, Eclipse Jetty) can be configured to encrypt. For example, see Tomcat SSL Security - How To guide for more information.
Platform Security
EBP runs within a J2EE Application Server or Servlet Container and is subject to its file permissions to obtain access to its configuration files, spools and datasets. This even applies to the standalone EBP server which runs under the Eclipse Jetty Servlet Contailer. These servers are configured to run under specific user and group IDs and therefore EBP is running under the same user -- it does not impersonate authenticated users from the directory server as it creates or accesses files. In this way the authentication directory server does not need to be configured as the local operating system's authentication system (although it can be). EBP's configuration file and default location for spools are within the extracted location of the EBP WAR file within the server. Take care to protect it against write (and possibly read) access from regular users that may be sharing the platform. If you change the configuration of EBP to define, for example, the datalib.1..n dataset locations, job input queue, output spool, temporary working spool locations elsewhere, such as on NFS mounted drives, take care to protect them as well.
Authentication
EBP and ETP use Java security to determine rights of Web service clients and may be integrated into your container's security mechanism. See your application server or servlet container documentation for more information.
Enabling security may require modification of the EBP/ETP web.xml file which instructs the container what services are allowed and how to authenticate users and classify services into groups that can be operated by those users with certain roles. Initially EBP knows about two roles, EBP-user and EBP-admin. There are no initial roles that are defined for ETP. See Authorization for more information on roles. After EBP is deployed into the web server you can change the web.xml to remove the comments around the security section in order to turn on Java Authentication and Authorization (JAAS) api standards and hook into the Heirloom RAC module that supports them:
<!-- to turn on EBP security, uncomment this section and define
users for roles "EBP-admin" and "EBP-user" in your server's
basic authentication file, e.g., tomcat-users.xml - - >
<security-constraint>
<web-resource-collection>
<web-resource-name>Require basic auth for EBP admin services</web-resource-name>
<url-pattern>/list</url-pattern>
<url-pattern>/define</url-pattern>
<url-pattern>/undefine</url-pattern>
<url-pattern>/start</url-pattern>
<url-pattern>/stop</url-pattern>
<url-pattern>/quiesce</url-pattern>
<url-pattern>/lock</url-pattern>
<url-pattern>/config</url-pattern>
<url-pattern>/console</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>EBP-admin</role-name>
</auth-constraint><user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint><security-constraint>
<web-resource-collection>
<web-resource-name>Require basic auth for EBP user services</web-resource-name>
<url-pattern>/list</url-pattern>
<url-pattern>/submit</url-pattern>
<url-pattern>/cancel</url-pattern>
<url-pattern>/restart</url-pattern>
<url-pattern>/purge</url-pattern>
<url-pattern>/console</url-pattern>
<url-pattern>/config</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>EBP-user</role-name>
</auth-constraint><user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
< ! - - end of uncomment security section -->
To uncomment these sections change the XML comment lines to have both beginning and ending comment tags, i.e <-- and --> without spaces:
<!-- to turn on EBP security, uncomment this section and define
users for roles "EBP-admin" and "EBP-user" in your server's
basic authentication file, e.g., tomcat-users.xml -->
The section in the web.xml file can be simplified further if you want to protect the entire EBP system, including the home pages:
<!-- to turn on EBP security, uncomment this section and define
users for roles "EBP-admin" and "EBP-user" in your server's
basic authentication file, e.g., tomcat-users.xml - - >
<security-constraint>
<web-resource-collection>
<web-resource-name>Require basic auth for all</web-resource-name>
<url-pattern>/</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>EBP-user</role-name>
<role-name>EBP-admin</role-name>
</auth-constraint>
<user-data-constraint><transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>< ! - - end of uncomment security section -->
Turning authentication on in EBP by making modification to its web.xml should be done after configuring other facets of authentication (LDAP, EBP rac.* settings) may prevent you from using the config Web service to complete configuration. Start EBP with the default web.xml first, then configure the other components and update the web.xml deployment descriptor later.
Turn security on in ETP by modifying the project.etp_deploy_settings of the Resource Access Control tab within the ETP Project dialog box. Set the Realm input field to a value to be displayed in the signon dialog box the browser will display (e.g,, "Please Signon") unless you have configured your Java Application Server to display a formal signon page in response to HTTP 302 (signon needed to continue) pages. Set the Role (Group) input field to the servlet role the authorized users should be a part of (e.g., "USERS"). Both Realm and Role fields are used to replace values within the web.xml template defined in the Java EE folder of an ETP deployment project that the ETP Deployment Wizard uses to create the final web.xml file inserted into the deployed .war or .ear file. You can update the web.xml file directly with these Web server context parameters if creating files through other build tools make, ant or maven.
Also change various RAC configuration settings in the table on that page. At minimum the rac.connectionurl must be changed to indicate the host and port number of a directory server that accepts LDAP protocol. For the OpenLDAP server the connectionurl value would be ldap://localhost:389/, for the Apache Directory Server the connectionurl value would be ldap://localhost:10389/. Microsoft Active Directory, IBM RACF® and Tivoli Directory Server and others also support this protocol. Secure LDAP protocol (ldaps://) is also available from many of these servers.
Fig. 1. RAC settings of an ETP Project within Elastic COBOL IDE
These steps merely set up the Web application (EBP or your EBP deployed app) to be checked by the container (e.g., Tomcat) when accessed by Web clients. To configure the containers themselves requires additional configuration. Tomcat and all J2EE servers have a variety of ways to configure the security components. In Tomcat this is knows as establishing a security Realm. The default is Tomcat's MemoryRealm which loads users, passwords and role (group) definitions into memory and checking requests against them. This realm stores its users in a tomcat-users.xml file (the name and location of which is in Tomcat's configuration file, server.xml). To define a user that has regular user operation rights, one that has admin rights and one that has both, define the following in Tomcat's tomcat-users.xml file, shown here for EBP configurations:
<role rolename="EBP-admin"/>
<role rolename="EBP-user"/>
<user username="ebpuser" password="abc000" roles="EBP-user"/>
<user username="ebpadmin" password="abc000" roles="EBP-admin"/>
<user username="ebp" password="abc000" roles="EBP-admin,EBP-user"/>
Tomcat and J2EE application servers can be configured to use different authentication and authorization mechanisms. In order to provide the same groups and user resource access control provided by RACF®, TopSecret or ACF2, you can use lightweight directory access protocol (LDAP) found in servers such as OpenLDAP, Apache Directory Server or Microsoft Active Directory. If the mainframe will remain in the picture with a Heirloom Computing rehosted enterprise application you can even use IBM RACF as a lightweight directory server. LDAP is the closest parallel to mainframe level resource access control. You can use mainframe tools from the vendor of the security subsystem (RACF, ACF2, TopSecret) to extract existing groups and users into files that can be easily converted to lightweight directory interchange format (LDIF) files. LDIF files are then imported into an LDAP server. For example, the LDAP server is defined with a simple naming "schema", one that knows about organizations, companies and domains. For more complex user ids and the groups (roles) that contain them, you tell the LDAP server about additional "Internet Organization" that Tomcat's default API knows about. Also you must define to the LDAP server your top level domain. To do this, after slapd (OpenLDAP) server is installed update the sldap.conf file:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema...
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
For theor apacheds (Apache Directory Serer) the default LDAP schema are already defined. ApacheDS has the notion of "partitions" for different directory entry groupings. By default, the "example.com" partition is defined and the examples contained in this paper use that same domain. However, you will need to modify the ApacheDS configuration files for your own cn. Also useful is the ApacheDS Studio, a Java GUI program to view and edit the directory entries for any LDAP server.
In the above example, the company top level domain name is "example.com" has the LDAP designation "dc=example,dc=com". Note also that an OpenLDAP "super user" is defined as "Manager" with password "secret". To carry out the additional configuration steps you need to use these names. See OpenLDAP documentation on how to better secure the system with digests, encrypted passwords, etc.
Update an initial LDIF file, such as setup.ldif with initial structure of groups, roles, and users. In the following example, two users are defined jjones, given the role of an EBP-user and fbloggs, given the role of both EBP-user and EBP-admin.
# EBP Resource Access Control - Sample authorization LDAP entries
# OpenLDAP slapd.conf file should already define the top-level entry
# here with optional organization attribute
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
objectClass: top
dc: example
o: engineering
# OpenLDAP slapd.conf file should already define a Manager role
dn: cn=Manager,dc=example,dc=com
objectClass: organizationalRole
objectClass: top
cn: Manager
# Define the overall "people" group containing all users, the name
# is referenced in EBP configuration rac.userpattern used by RAC
# to search for users (default "uid={0},ou=people,dc=example,dc=com")
dn: ou=people,dc=example,dc=com
objectClass: dcObject
objectClass: organizationalUnit
objectClass: top
dc: example
ou: people# Define a user entry for Janet Jones
dn: uid=jjones,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: jjones
sn: jones
cn: janet jones
mail: j.jones@example.com
userPassword: abc000# Define a user entry for Fred Bloggs
dn: uid=fbloggs,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: fbloggs
sn: bloggs
cn: fred bloggs
mail: f.bloggs@example.com
userPassword: abc000# Define an entry to contain LDAP groups
# searches for roles are based on this entry
dn: ou=groups,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: groups# Define an entry for the "EBP-admin" role, users that can
# administer EBP by defining job classes, start initiators,
# perform a system quiesce, and modify configurations
dn: cn=EBP-admin,ou=groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: EBP-admin
uniqueMember: uid=fbloggs,ou=people,dc=example,dc=com# Define an entry for the "EBP-user" role, users that can
# submit batch jobs, cancel or checkpoint running jobs, restart
# queued jobs, or purge completed jobs
dn: cn=EBP-user,ou=groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: EBP-user
uniqueMember: uid=fbloggs,ou=people,dc=example,dc=com
uniqueMember: uid=jjones,ou=people,dc=example,dc=com
You then add these entries into the OpenLDAP system with the ldapadd command.
ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f setup.ldif
After supplying the password ("secret" in this example), the entries are added. Note that if you are replacing existing entries instead of adding them to the directory the first time you should recursively remove existing entries first. That command is ldapdelete:
ldapdelete -x -W -D "cn=Manager,dc=example,dc=com" -r "dc=example,dc=com"
To verify they are in the system you can issue the ldapsearch command,
ldapsearch -x -b "dc=example,dc=com" "(objectclass=*)"
the results of which are:
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
## example.com
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
o: engineering
dc: example# Manager, example.com
dn: cn=Manager,dc=example,dc=com
objectClass: organizationalRole
cn: Manager# people, example.com
dn: ou=people,dc=example,dc=com
objectClass: dcObject
objectClass: organizationalUnit
dc: example
ou: people# jjones, people, example.com
dn: uid=jjones,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: jjones
sn: jones
cn: janet jones
mail: j.jones@example.com
userPassword: abc000# fbloggs, people, example.com
dn: uid=fbloggs,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: fbloggs
sn: bloggs
cn: fred bloggs
mail: f.bloggs@example.com
userPassword: abc000
o: 997
# Operator ID (OPID) optionally set with the config "rac.opidattribute" LDAP attribute, default "o"# groups, example.com
dn: ou=groups,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: groups# EBP-admin, groups, example.com
dn: cn=EBP-admin,ou=groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: EBP-admin
uniqueMember: uid=fbloggs,ou=people,dc=example,dc=com# EBP-user, groups, example.com
dn: cn=EBP-user,ou=groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: EBP-user
uniqueMember: uid=fbloggs,ou=people,dc=example,dc=com
uniqueMember: uid=jjones,ou=people,dc=example,dc=com# search result
search: 2
result: 0 Success# numResponses: 9
# numEntries: 8
GUI tools for editing LDAP directory entries are available from many sources.
- Apache Directory Server Studio may be used (even with OpenLDAP) as an Eclipse plug-in or stand-alone version
- JExplorer LDAP Directory Browser available as a stand-alone application
The Apache Studio as an Eclipse plug-in is shown below:
Fig. 2. Apache Directory Studio LDAP browser within Eclipse.
J2EE servers can use JNDINaming to authenticate users against an OpenLDAP server using the information above and then inform EBP/ETP of the authenticated user for each request. This partial authentication/authorization model does not require EBP/ETP to access the directory server and makes EBP/ETP configuration simpler. However, EBP/ETP cannot perform authentication of specific resources other than when Web services are invoked.
In Tomcat, the Realm specification triggers the authentication check and can be part of either the global Tomcat server.xml configuration or in the EBP Web application META-INF/context.xml file, which includes Realm specification for the JNDIRealm Tomcat component. remove the comments from the META-INF/context.xml file after EBP/ETP is deployed or update the global server.xml file to contain the Realm specification:
<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionURL="ldap://localhost:389"
userPattern="uid={0},ou=people,dc=example,dc=com"
roleBase="ou=groups,dc=example,dc=com"
roleName="cn"
roleSearch="(uniqueMember={0})"
/>
The JNDIRealm shown above operates in bind mode, where the OpenLDAP server validates the basic authentication headers in the HTTP request before invoking the EBP/ETP Web service. You can create an "EBP Login Page" (not provided) to ask your users to log in and set these headers for Web service requests if you will be allowing end-users to use, for example, the EBP System Console or Web services index.html page directly. requests. If no headers are in effect at the time of the initial EBP Web services request, Tomcat will return an HTTP 403 error code causing most browsers to display a small pop-up asking for user and password.
Although Tomcat JNDIRealm also supports comparison mode, where applications can request passwords from the directory server and then compare them with information obtained from the user (e.g., a PASSWORD keyword on a JOB card), EBP will not use this mode as most consider it a back-door that bypasses basic security mechanisms and leaves the door open to attack.
If you will be using EBP/ETP to allow or deny access to certain resources (datsets, jobs, etc.) or to lock out ETP transactions or programs to groups of users -- batch and online hosted on the same Tomcat -- you may consider using the Tomcat JAASRealm authentication system. This offers full authentication and authorization capabilities. Often ETP users include a CESN/CESF logon/logoff set of transactions in their application to authenticate users for other transactions or explicitly use the EXEC CICS SIGNON API call within their COBOL applications to ask for user/password authentication explicitly. ETP will associate the validated users and groups with the session and apply it when invoking other transactions when transaction-level security is in effect.
Unlike the JNDIRealm, the JAASRealm does allow EBP to check USER and PASSWORD keywords on the JOB card against an LDAP server. You configure such a realm in Tomcat with the Realm directive in Tomcat's server.xml file or uncommenting the appropriate section in or in the EBP Web application META-INF/context.xml file.
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="EBP"
userClassNames="com.heirloomcomputing.ecc.RACUser"
roleClassNames="com.heirloomcomputing.ecc.RACRole"/>
The above tells a authentication checker built-into Tomcat about the LDAP directory structure, specifically to look for user IDs in the uid section of each distinguished name and to search for roles in the LDAP groups section. After authenticating (and authorizing, depending on the EBP/ETP web.xml settings mentioned above) it will inform EBP of the Java Principal name (user name) and the roles associated with that user to all EBP/ETP Web service calls in the authorization step.
To allow EBP/ETP to do authorization using the JAASRealm model you must configure a number of EBP/ETP settings. See the rac.* group of settings in EBP Configuration. The default settings are sufficient to implement the LDAP directory structure of examples contained in this document. See the Installation section later in this article for further discussion.
Authorization
Authorization means placing users in one or more groups and then granting rights to those groups for various services or resource classes. There are two forms of authorization supported by EBP and ETP. The first checks that only users in certain roles (groups) are allowed to process EBP/ETP Web services. If a user can submit a job, it will run. The second requires full Resource Access Control to be enabled and will verify JCL jobs have access to resources such as job queues and datasets before they are run or during execution. Jobs running under RAC will ABEND if they cannot access the resources they need.
For the initial Web services authorization, there are two role EBP checks for, users and administrators. The user role is for manipulating jobs -- submitting them, canceling them, displaying the contents of their output, etc. The administrator role allows configuration of EBP, define job classes, start/stop initiators, quiesce the system or perform EBP-Plex (clustering) operations. Note that administrators don't ordinarily have the right for user operations -- the ability to submit jobs. But, you can define users that take on multiple roles in most server environments.
You may also need to change the EBP Configuration for the userrole and adminrole that match those imported into your OpenLDAP server. These names appear in the web.xml deployment descriptor as well. The configuration settings, their default roles and the Web services allowed under those roles are as follows:
- ebp.userrole=EBP-user: submit, cancel, purge, checkpoint, restart, list, console, config (read-only)
- ebp.adminrole=EBP-admin: quiesce, define, undefine, start, stop, list, console, config, lock
Generally, the EBP index.html home page and the sysoper.html System Operators console and their components can be allowed to be accessed by all users. But, your organization may set up other logon pages that set the security contexts before any part of EBP becomes visible and/or remove visibility of these "internal" pages entirely.
When security is turned on for the Web server (Java security principle names and their roles are available), EBP will enforce a cascading set of ownership of jobs. The authenticated user (in the EBP-user role) will become the owner of jobs submitted by the submit Web service. Listing the status of jobs will include that user name in the output, visible on the System Operators Console. When JCL jobs are run by EBP the &SYSUID symbolic parameter is set to the upper-case representation of the user (&sysuid is the lower case representation). Only that same user or one with both an EBP-user and EBP-admin role may cancel, purge, checkpoint or restart that job. Further, any jobs submitted to the internal reader either in JCL or through COBOL API will take on the same user as that which submitted the original job.
EBP/ETP also checks if the user is authorized to access to external resources such as datasets. Linux, UNIX, MacOS and Windows operating systems govern access to files by the J2EE Application Server or Servlet Container (which may or may not be tied to the same LDAP server checking EBP access). Often files backing the EBP/ETP datasets are "all access" to the user ids underwhich the servers run. An added layer of security to access datasets will be made by EBP/ETP when operating in a secure mode, for example when JAASRealm or JNDIRealm are configured in Tomcat.
The users authenticated by the EBP container will override the USER keyword that may be present on the JOB card. the USER and PASSWORD job card keywords are not used to authenticate against OpenLDAP when Tomcat is configured to use JNDIRealm authentication. However, the USER and PASSWORD entry on the job card will still be used to authenticate access to resources such as with database connections performed by DSNTIAD and IKJEFT01. Note that EBP cannot learn LDAP passwords in order to pass them to database connections. However, JNDI naming and JDBC datasources can be established to allow the container to validate database connections used by job steps.
In ETP your transactions can invoke the EXEC CICS SIGNON and EXEC CICS SIGNOFF statements to authenticate with a particular user and password before beginning other operations. If no authentication is performed all transactions run under the user ID CICSUSER.
Although authorization of EBP/ETP Web services can be provided by the simple text-file or JNDIRealm level partial authentication models, the more complete Resource Access Control with its ability to lock specific resources or resource groupings requires the full JAASRealm configuration. To allow EBP/ETP to do authorization using the JAASRealm model you must configure a number of EBP settings. See the rac.* group of settings in EBP Configuration (these also apply to ETP settings set with the project.etp_deploy_settings file). The default settings are sufficient to implement the LDAP directory structure of examples contained in this document.
To enable full authorization you will need to define a JAAS property and start the J2EE Application Server or Servlet Container with a configuration file for it. The Tomcat start-up scripts look to JAVA_OPTS environment variable to set properties for Tomcat. Other app servers and Jetty have similar requirements.
JAVA_OPTS="$JAVA_OPTS -Djava.security.auth.login.config=$CATALINA_BASE/webapps/ebp*/META-INF/jaas.config"
The contents of the jaas.config can be placed anywhere but EBP and generated ETP wars and ears are generated with a copy of it in the META-INF folder after the war is unpacked. The contents define the Java class the JAAS security module should use to check initial login:
EBP {
com.heirloomcomputing.ecc.RACLogon required debug=true;
};ETP {
com.heirloomcomputing.ecc.RACLogon required debug=true;
};
When combined with the <Realm>...</Realm> specification above, EBP can be used under Tomcat for both authentication and authorization, a facility called Heirloom Computing Resource Access Control module, part of the Heirloom product.
Resource Access Control (RAC) allows EBP to check an external directory server to authorize users of resources. EBP can check the following resource types: groups:
- datasets
- jobclasses
- outputclasses
- transactions
- programs
The access rights are granted for a particular resource or a resource pattern and granted (or denied) to a group. Users can be part of one or more groups and multiple access rights can be applied to an individual resource or resources meeting a pattern.
EBP/ETP RAC configuration directives are used to define the actual resource type names and the directory attributes that are used to find them. RAC leverages the same configuration mechanism as the JAASRealm security model for authentication, extended from roles to resources. You configure LDAP attributes and search criteria in EBP/ETP configuration and then insert records into a JNDI directory server as with users and groups. Below is an example of an LDIF file that defines the RAC resource groupings and then resources within them.
# EBP Resource Access Control - Sample authorization LDAP entries
# Create one more user and two groups used for granting access
dn: uid=jblow,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Joe Blow
initials: jb
sn: joe
uid: jblow
userPassword: abc000
# Define the SYSDEV group containing Fred and Janet
dn: cn=SYSDEV,ou=groups,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
cn: SYSDEV
description: A group of only system developers
uniqueMember: uid=jjones,ou=people,dc=example,dc=com
uniqueMember: uid=fbloggs,ou=people,dc=example,dc=com
# Define the USERS group containing all users
dn: cn=USERS,ou=groups,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
cn: USERS
description: All users are members of the USERS group
uniqueMember: uid=fbloggs,ou=people,dc=example,dc=com
uniqueMember: uid=jjones,ou=people,dc=example,dc=com
uniqueMember: uid=jblow,ou=people,dc=example,dc=com
# Define the overall "datasets" resource access control category
# referenced in EBP configuration rac.resourcetypes
dn: ou=datasets,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: datasets
# Define the overall rule for all datasets unless covered by other rules
# Note: because groupOfUniqueNames must have at least one uniqueMember,
# it specifies the same permissions as the base object
dn: cn=*,ou=datasets,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: deny:all
cn: *
description: By default, no usage of datasets are permitted by anyone unless otherwise specified
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=deny:all
# Define the overall rule for usage of datasets beginning with the high level qualifier 'HCI00',
# namely only properly authenticated USERS have full access unless otherwise specified
dn: cn=HCI00.*,ou=datasets,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: deny:all
cn: HCI00.*
description: High Level Qualifier for most HCI datasets are fully accessible to all authenticated USERS
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=allow:all
# Define a rule denying all access to datasets beginning with 'HCI00.DEVCODE' to everyone except
# members of the SYSDEV group, who have all access (specified two different ways through different uniqueMembers
# and businessCategory's)
# Note: Wildcard '.*' allowed only at the end of dataset qualifiers at this time to improve LDAP search performance,
# patterns such as '.**', '.*.**', 'PART*.*', etc are not enforced
dn: cn=HCI00.DEVCODE.*,ou=datasets,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: deny:all
cn: HCI00.DEVCODE.*
description: All DEVCODE is available only to SYSDEV people unless specific datasets are otherwise marked
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:alter
# Although the previous rule denied access to most users to the 'HCI00.DEVCODE' tree of files, define
# another rule that allows a specific file 'HCI00.DEVCODE.PURCHASE.LIST' to be read by all USERS
# Note: Since the most specific rule is matched first (this rule before 'HCI00.DEVCODE.*"), SYSDEV
# must be given the allow:all right here as well as 'HCI00.DEVCODE.*'
dn: cn=HCI00.DEVCODE.PURCHASE.LIST,ou=datasets,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: allow:all
cn: HCI00.DEVCODE.PURCHASE.LIST
description: This listing dataset is avalable to everyone
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:all
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=allow:read
# Define the overall "transactions" resource access control category
# referenced in EBP configuration rac.resourcetypes
dn: ou=transactions,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: transactions
# By default, anyone can execute most transactions in ETP
# Note: because groupOfUniqueNames must have at least one uniqueMember,
# it specifies the same permissions as the base object
dn: cn=*,ou=transactions,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: allow:execute
cn: *
description: Default transactions executable by anyone, even non-authenticated users
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=allow:execute
# Only the ETRN transaction may be executed by SYSDEV
dn: cn=ETRN,ou=transactions,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: deny:all
cn: ETRN
description: The ETRN transaction, only SYSDEV members may execute it
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:execute
# Define the overall "programs" resource access control category
# referenced in EBP configuration rac.resourcetypes
dn: ou=programs,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: transactions
# By default, anyone can execute most programs in ETP
# Note: because groupOfUniqueNames must have at least one uniqueMember,
# it specifies the same permissions as the base object
dn: cn=*,ou=programs,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: allow:execute
cn: *
description: Default transactions executable by anyone, even non-authenticated users
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=allow:execute
# Only the ETPETRN program may be executed by SYSDEV
dn: cn=ETPETRN,ou=programs,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: deny:all
cn: ETPETRN
description: The ETPETRN program, only SYSDEV members may execute it
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:execute
# Define the overall "jobclasses" resource access control category
# referenced in EBP configuration rac.resourcetypes
dn: ou=jobclasses,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
businessCategory: allow:all
ou: jobclasses
# By default, anyone can submit jobs to any job class
# Note: because groupOfUniqueNames must have at least one uniqueMember,
# it specifies the same permissions as the base object
dn: cn=*,ou=jobclasses,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: allow:all
cn: *
description: By default all users may submit jobs to any class unless otherwise specified for a particular class
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=allow:all
# Define a rule that allows only SYSDEV members to submit jobs to class Q
dn: cn=Q,ou=jobclasses,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: deny:all
cn: Q
description: Only SYSDEV personnel are allowed to submit and cancel to class Q; no one can checkpoint or restart
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:submit/allow:cancel
# Define the overall "outputclasses" resource access control category
# referenced in EBP configuration rac.resourcetypes
dn: ou=outputclasses,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: outputclasses
# By default, anyone can specify SYSOUT= to any output class unless otherwise specified
# Note: because groupOfUniqueNames must have at least one uniqueMember,
# it specifies the same permissions as the base object
dn: cn=*,ou=outputclasses,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: allow:all
cn: *
description: By default all user's jobs may send SYSOUTs to any output class unless otherwise specified for a particular class
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=allow:all
# Only members of the SYSDEV group can send output to the Q output class
dn: cn=Q,ou=outputclasses,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: deny:all
cn: Q
description: Only members of SYSDEV can view and purge SYSOUTs sent to output class Q
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:update/allow:view/allow:purge
See the attached h-rac.ldif for a complete meta-data description of a directory suitable for RAC and same entries.
The standard core LDAP schema defines groupOfUniqueNames object class to contain businessCategory which EBP/ETP (configured appropriately) will use to define the access type (allow or deny) and the access right. Access rights cascade. A dataset update (DISP=OLD) right implies the ability to also read (DISP=SHR). Dataset access alter right (DISP=NEW,DELETE) implies update which allows read by users that are members of the group that is granted that right. The businessCategory attribute on the resource itself indicates the default for all groups that are not explicitly denied or allowed access in one or more uniqueMember attributes.
| Category | Privilege | Description | Implies |
| datasets | alter,all | Allows datasets to be created or deleted (DISP=NEW, DELETE or UNCATLG) | update, read |
| update | Allows datasets to be written (DISP=MOD or OLD) | read | |
| read | Allows dataset to be read (DISP=SHR) | ||
| jobclasses | submit,all | Allows a job to be submitted to a particular class | cancel |
| cancel | Allows a running job to be canceled (owner only) | ||
| outputclasses | purge | Allows a completed job to be purged (owner only) | view |
| view | Allows a SYSOUT dataset to be viewed (owner only) | ||
| transactions | execute | Allows a transaction to be executed within ETP |
Resources and access rule permissions may be specified as an exact resource name (job class A, dataset A.B.C.D) or with wildcards in the last segment in which that rule will match all resource patterns below it (dataset A.B.*). Unlike some systems, multiple wildcards, embedded wildcards and the ** wildcard are not supported as they would require an entire LDAP search. A resource that consists only of a wildcard (job class *, dataset *) defines the default permissions for the entire resource type. Multiple rules will be looked up in the server until one is matched against the requested resource. For the permission to update dataset A.B.C.D, for example, the resource record for A.B.C.D is looked up. If not found, A.B.C.* is retrieved, then A.B.*, A.* and finally *. Once rules are attached to a rule retrieval is stopped whether or not there are group permissions for one of the current user's groups or a default allow or default deny specification, implying a "deny:all" default rule.
Resource Groups
Later versions of IBM RACF® allowed for resource groups, specific groups containing references to specific resources. Users and groups could then be granted access to a group rather than a specific resource, simplifying granting groups of users to groups of resources. This is represented in RAC with the (optional) LDAP entries as represented by the following LDIF file:
# EBP Resource Access Control - Sample authorization LDAP entries
# Define the notion of 'resourcegroups', a list of resource group names
dn: ou=resourcegroups,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: resourcegroups
description: Groups of resources
# Create a resource group of read-only transactions that only read a dataset
dn: cn=readonly,ou=resourcegroups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: readonly
description: M:N relationship between resources and groups that can execute read-only transactions
uniqueMember: cn=init,ou=transactions,dc=example,dc=com
uniqueMember: cn=emnu,ou=transactions,dc=example,dc=com
uniqueMember: cn=eson,ou=transactions,dc=example,dc=com
uniqueMember: cn=esof,ou=transactions,dc=example,dc=com
uniqueMember: cn=epic,ou=transactions,dc=example,dc=com
uniqueMember: cn=HCI00.READONLY.DAT,ou=datasets,dc=example,dc=com
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=allow:execute
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:execute
businessCategory: deny:all# Create a resource group of update transactions that change a dataset
dn: cn=update,ou=resourcegroups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: update
description: M:N relationship between resources and groups that can execute update transactions
uniqueMember: cn=etrn,ou=transactions,dc=example,dc=com
uniqueMember: cn=ecnt,ou=transactions,dc=example,dc=com
uniqueMember: cn=ejnl,ou=transactions,dc=example,dc=com
uniqueMember: cn=HCI00.READWRIT.DAT,ou=datasets,dc=example,dc=com
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:execute
businessCategory: deny:all
As with individual resource entries, the resource group entries define their default permissions with the businessCategory entry which are overridden with the businessCategory on the value of the uniqueMember.
Merging of access control lists is performed at system startup by loading all resource group rules and the individual access rights on a resource. It is best to not have conflicting rules, the rules that emerge as part of any conflict as the ordering of LDAP entries is undefined. For example, there may be two resource groups that mention the same program, but the groups contained in each are different -- a conflict cannot occur. But, two resource groups may contain the same resource names and group names. If they do, it is best to have them contain the same rights (e.g., allow:execute or deny:all). In a similar situation with datasets if one group specified allow:read and the other allow:write it is undefined which takes precedence. Further, if a resource group contains a rule for a group USERS to allow:execute but the transaction it contains is mentioned in the transactions set of resources with a different specification for USERS (e.g., deny:all) the resulting rule is also undefined.
RACF® and RAC Parallels
Relationship between entries within an LDAP directory can be directly correlated to their RACF® counterparts, and vice versa. Wheras you would create a RACF® resource group profile called ACCOUNTING which gives all users in groups DEPT45 and DEPT85 access to 3 specific transactions you would write in RACF®:
RDEFINE TCICSTRN ACCTTX UACC(NONE)
ADDMEM(CEMT, CEDA, CEDB)
PERMIT DEPT45 CLASS(TCICSTRN) ID(DEPT45) ACCESS(READ)
PERMIT DEPT85 CLASS(TCICSTRN) ID(DEPT85) ACCESS(READ)
and the equivalent RAC LDIF file would be:
# Create a resource group of update transactions that change a dataset
dn: cn=ACCTTX,ou=resourcegroups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: ACCTTX
description: Update transactions and datasets that may be updated
uniqueMember: cn=CEMT,ou=transactions,dc=example,dc=com
uniqueMember: cn=CEDA,ou=transactions,dc=example,dc=com
uniqueMember: cn=CEDB,ou=transactions,dc=example,dc=com
uniqueMember: cn=DEPT45,ou=groups,dc=example,dc=com,businessCategory=allow:execute
uniqueMember: cn=DEPT85,ou=groups,dc=example,dc=com,businessCategory=allow:execute
businessCategory: deny:all
Note also you can get closer to RACF® nomenclature by changing the names of schema entries to their IBM names. For example, the ou=transactions could be named ou=TCICSTRN to more closely parallel the RACF® resource class for transactions. LDIF lookup is generall case-insensitive -- see the configuration of your LDIF server.
Extending RAC Security to Other Web Services
Since the Heirloom Computing RAC module is a standard JAAS API component, you can configure other Java services running on the Application Server or Servlet Container to use it. Use the same information contained here to modify the application's web.xml file and configure the jaas.config files to have the server invoke the standard APIs to check user and password when Web services are requested by Web clients. Standard HTTP 303 errors will be returned to the client (e.g., a browser), causing them to display a "logon" dialog box of some sort. Follow-up requests to the same Web service will then send encrypted user and password information which will be checked by RAC.
Applications can use the advanced features of RAC to check resources in the same way as EBP does. Those applications can invoke standard JAAS Authorization APIs to verify access to files, pages, or application-specific resources like account numbers.
Installation and Configuration
RAC components are in the standard distribution of EBP/ETP. To use the simplest text-based authentication mode (e.g., by updating users and groups in tomcat-users.xml) you only need modify the web.xml deployment descriptor and that's it.
To use the more advanced JNDIRealm authentication model, change your J2EE application server's configuration to use an OpenLDAP server following that server's documentation.
To allow both authentication and authorization you use the JAASRealm configuration involving setting up a new directory server and loading it with your resource control rules. Download OpenLDAP for Windows or Linux from www.openldap.org or use JNDI directory servers compatible with JNDI from IBM (z/OS RACF®, Tivoli Directory Server), Microsoft (Active Directory), Red Hat (JDI) or others. Set up OpenLDAP and modify the attached h-rac.ldif for your installation by changing the dc=example and dc=com.
Before configuring the web.xml deployment descriptor and starting EBP/ETP with RAC enabled, start EBP without RAC and update the necessary rac.* configuration settings, for example, changing dc=example and dc=com. Update the web.xml descriptor to turn on authentication, update the server's start-up options to include the -Djava.security.auth.login.config property indicated above and restart the server.
Some JEE servers have a different way of configuring JAAS instead of setting the java.security.auth.login.config property. On JBOSS, for example, you insert a new security-domain into the jboss.xml, standalone.xml or domain.xml (latter two correspond to Wildfire stand-alone and domain operation):
<security-domain name="EBP" cache-type="default">
<authentication>
<login-module code="com.heirloomcomputing.ecc.RACLogon" flag="required"/>
</authentication>
</security-domain>
Note in this configuration the security credentials are cached using a "default" timing mechanism. See JBOSS documentation for this timeout value. There is a corresponding entry in the WEB-INF/jboss-web.xml file distributed with EBP directory, these names must match:
<jboss-web>
<security-domain>EBP</security-domain>
</jboss-web>
EBP Configuration rac.* settings mirror many of those involved with setting up the Apache Tomcat JAASRealm authentication mechanism. They define the way EBP interacts with an LDAP server to authenticate users and determine their group membership. Added to these are configuration settings for resource authentication purposes. All configuration defaults except for various domain name references and rac.connectionurl naming the path to the LDAP server (e.g., ldap://localhost:389 ) are sufficient for basic startup with a local OpenLDAP server under your control. If attaching to an external LDAP server that may be locked down from anonymous verification or search may require additional settings.
Only if the LDAP server is locked to anonymous look-up do the rac.connectionuser and rac.connectionpassword need to be specified with information from your security administrator for general access and search for users, roles (groups) and resources.
The rac.usersearchasuser, rac.rolesearchasuser and rac.resourcesearchasuser may be set to true indicating that the currently authenticated user (instead of anonymous) is used to bind to the LDAP server and search for these items. The user/password that is sent with the Web service request to EBP may be checked in one of two ways. Without rac.userpassword being set, EBP will act in bind mode to attempt to connect to the server with the user and password. A failure to bind is interpreted as an invalid password usually resulting in an HTTP 403 error to be sent as the response, as determined by the Web server. But, EBP can operate in comparison mode when rac.userpassword is set to the directory attribute (usually userPassword in an inetOrgPerson schema structure for defining users).
Should it become necessary to authorize a user that hasn't yet been authenticated then a user search is instituted. This can come about in EBP when a user was authenticated at one time (in order to submit the job) but an EBP restart occurred when the job is ready for execution. No user/password combination is available to do a bind (passwords are not saved). Another case is when the JCL of a job queued by ESP contains the USER specification on the job card but no password is defined. When the job is ready to run and is running EBP will check the authorization for these un-authenticated users to access resources such as output classes and datasets. A search of the LDAP directory is performed with the help of rac.usersearch pattern (default (uid={0}) ) and rac.userbase (default ou=people,dc=example,dc=com). From this information the user and the groups they are in are looked up to determine if they have access to the requested resources.
Searches are also performed if you would like to authenticate users based on their e-mail address instead of a component of the distinguished name. In this case the rac.usersearch pattern would be (mail={0}) where mail is the LDAP attribute name indicating the e-mail address.
Many of the rac.* configurations set up attribute names of the directory structure or search criteria used to find information. The defaults are typical for the recommended inetOrgPerson / cosine / CoRE RFC standards document for defining a directory layout. But, if you are working with another directory structure (such as connecting directly to the LDAP proxy for IBM RACF®) you will likely need to change rac.userpattern (default uid={0},ou=people,dc=example,dc=com) which indicates (through {0} place mark) the pattern for user look up. For instance, your organizational unit indicating the group of all users (and definitely domain information) may be different on your server.
If people login with e-mail accounts instead of user id fields that are part of the distinguished name for this directory element, EBP can conduct a search (scan) of the directory when rac.usersearch indicates the attribute (e.g., emailAddress) to use. See other LDAP documentation or Tomcat JNDIRealm configuration for further discussion.
The various resource configurations follow along the same line as user and roles. In our sample implementation, the resource types are defined as LDAP directory class organizationUnits with names for each grouping defined in rac.resourcetypes. If you organize your directory differently with different group names for datasets, jobclasses, etc. you will need to update rac.resourcetypes but keep them in the same order as EBP will request, for example, resource type 1 for job class authorizations. RAC needs three configurations to figure out how to retrieve the members (resources) in these resource type groupings and the corresponding group and rules. The rac.resourcebase indicates how to look up a resource directory entry (default cn={0},ou={1},dc=example,dc=com) by substituting the {0} with the resource name (e.g., SYS1.PROCLIB.DEV.PDS) or pattern (e.g. SYS1.PROCLIB.*) and {1} with the resource type (from rac.resourcetypes). For configuration simplicity you can also specify {2}, {3}, {4}, etc. instead of explicit domain names for the JNDI name parts of the currently authenticated distinguished name, especially if multiple domain names are contained in the same server. The default RAC configuration is set up to store resources like roles, as groupOfUniqueNames object class elements. in the directory and rac.resourcememberattribute indicates the directory attribute name (default uniqueMember) that contains one or more group names and auth rules to check against. Finally, rac.resourceruleattribute indicates the directory attribute (default businessCategory) that contains auth rules. One or more rules may be specified on the resource itself or within the values of the uniqueMember attributes for the resource. The former defines the default rules for the resource if no more specific rule may be found for a group. The latter defines the rule applied to members of the group for that resource. Rules are of the form allow|deny:access1/allow|deny:access2. See the table above discussing cascading rights. Thus, the entry:
dn: cn=HCI00.DEVCODE.*,ou=datasets,dc=example,dc=com
objectClass: groupOfUniqueNames
objectClass: top
businessCategory: deny:all
cn: HCI00.DEVCODE.*
description: DEVCODE changeable by SYSDEV, readable by all USERS
uniqueMember: cn=SYSDEV,ou=groups,dc=example,dc=com,businessCategory=allow:update
uniqueMember: cn=USERS,ou=groups,dc=example,dc=com,businessCategory=allow:read
indicates that for datasets beginning with HCI00.DEVCODE members of the USERS group can read data (JCL DD cards indicate DISP=SHR) and folks in SYSDEV can update (DISP=OLD). Users that are not part of either group are denied all access. Users that are part of both groups will be processed in order ... therefore include to most liberal rights before the less restrictive rights. Note that on this entry, no one can create (DISP=NEW) or delete (DISP=(,,UNCATLG)) these datasets. Also note that many directory servers have case-insensitive search turned on so groups sysdev and SYSDEV are equivalent. Also note that the rules of the groupOfUniqueNames object class require at least one uniqueMember so even if you intend to give everyone the default right you must include some group specification with that same right.
Finally, you may not be connecting to an LDAP server at all, instead using JAAS to connect to some other form of JNDI server. You can change the rac.contextfactory to a Java class other than the default com.sun.jndi.ldap.LdapCtxFactory that JAAS uses as its directory context factory. Of course, the classes implementing these alternative contexts must be on the Web server's classpath.
The built-in JNDIRealm service of Tomcat will authenticate each Web service request against the directory server. However, RAC has a user, group and resource caching mechanism to reduce network traffic to the directory server. It is controlled through two settings, rac.cachetime (default 8 hours) and rac.cachesize (default 5000 users and 5000 resources). This may mean that even if you change someone's inclusion in a group, or the permissions on a resource, it won't be visible for up to 8 hours with the default settings. You can flush the memory-resident cache by cycling the J2EE server.
Note: Some Java Application Servers also cache authentication -- they will not invoke the RAC authentication mechanism for user/passwords that were authenticated at any time in the past. If you want the ability to change authorizations, delete users, etc. turn off caching. For example, in WildFly the setting is cache-type.
Note: A reminder that user/password authentication is performed when a Web service such as submit is invoked. EBP does not store passwords in external files. Thus, to remove permissions of queued jobs you should remove a user from a group or change that user's group permissions. Also, when EBP is stopped and started, or user/password are evicted from the cache, jobs queued to run later will authenticate either anonymously or use the rac.connectionuser and rac.connectionpassword if the directory server prevents anonymous look up. The rac.usersearchasuser, rac.rolesearchasuser and rac.resourcesearchasuser feature cannot be used as the cached password used to bind to the directory server is unavailable.
Troubleshooting
Turn on EBP RAC logging to see the interaction between RAC and the OpenLDAP server by setting the EBP configuration messages to yes, errorlevel to D and the special rac.debug setting to yes. The J2EE server's output log will contain messages as users, job classes and dataset authorities are checked.
The EBP home page config form can be used to make RAC configuration changes. In the "Other:" field on this form enter "rac.connectionurl" as the setting and "ldap://localhost:389" as its value and click OK. To review your RAC configuration, check the "Resource Access Control" box and click OK (do not use "Other:" and "Security" at the same time). After making changes, use the "Save" button to backup all EBP configuration settings in an external file. Alternatively, you can use curl or wget commands to make configuration changes from a BAT or shell script (see attached racon.sh).
This exception in the J2EE server log indicates that although the web.xml asks for security on EBP Web services and the context.xml is configured for JAASRealm operation the server has not been started with the "-Djava.security.auth.login.config" property:
SEVERE: Unexpected error
javax.security.auth.login.LoginException: No LoginModules configured for EBP
In summary, you should have performed at minimum the following steps to get EBP to check user/passwords on Web services and USER and PASSWORD keywords within JCL JOB cards:
- Deploy EBP to Apache Tomcat 8
- Install OpenLDAP (slapd service) on your system
- Create appropriate LDAP schemas with users, groups and job classes as indicated above
- Set EBP configuration with the Config Web service, the "Other" configurations on the main page form, to insert your organization's domain name:
- rac.connectionurl to ldap://localhost:389/
- rac.resourcesbase to cn={0},dc=your-domain,dc=your-domain-suffix
- rac.rolebase to ou=groups,dc=your-domain,dc=your-domain-suffix
- rac.userpattern to uid={0},ou=people,dc=your-domain,dc=your-domain-suffix
- rac.rgbase to uid={0},ou=resourcegroups,dc=your-domain,dc=your-domain-suffix
- Change the EBP deployment descriptor WEB-INF/web.xml to uncomment the security constraints (XML comments at the beginning and end of the block)
- Ensure Tomcat start up scripts (e.g., startup.sh, startup.bat, or /etc/init.d/tomcat8) turn on JAAS security checking (e.g., -Djava.security.auth.login.config=/var/lib/tomcat8/webapps/ebp##17.11.26/META-INF/jaas.config)
- Restart Tomcat, access http://localhost:8080/ebp and click on "List" service. The user/password dialog box for the LDAP user given access to the services should appear
The failure to see debugging logs after setting rac.debug=yes may mean that the RAC classes are not loaded into the JEE server or servlet engine. Ensure that the necessary jaas.config file is enclosed in the war or ear file. Also, if there are multiple war deployments (e.g., EBP batch executor and multiple ETP regions), the first one loaded will be used by all through the JEE server's class loader. Undeploying one application from the server will not reload the classes from another in many cases. Stop/Start your server to clear its class cache.
Examples
The complete sample LDIF file along with a script that reloads the entries into an LDAP server and another that configures EBP are attached to this article.
Creating Your Own RAC
The Resource Access Control module delivered with EBP and ETP act as described in this document. RAC interfaces with an LDAP server to authenticate users and passwords and authorize access to resources. However, you can create your own RAC module and register it with ETP and EBP to be used instead. You might do this if you have security checking rules that rely on something other than directory entries. For example, if you invoke Web services to ask a remote server for authentication and authorization information.
A Java interface is defined to provide a consistent interface for EBP and ETP to invoke. Define your RAC module such that it implements the com.heirloomcomputing.ecc.IRAC interface described in the javadoc. The IRAC definition is embedded within the ecobol.jar as com.heirloomcomputing.ecc.IRAC. The following methods must be implemented:
- Setup() - configure your custom RAC module with the supplied properties
- TearDown() - turn off RAC
- Authenticate() - authenticate a user password
- Authorize() - verify that a user is authorized to access a particular resource type and name
- GetGroupsForUser() - return all groups containing a particular user
- IsRACon() - return true if RAC checking is in force
See How To ... Integrate the Elastic COBOL Javadoc into Eclipse for more information on how to make it easier to implement Elastic COBOL interfaces in your native Java classes.
The ETP deployment property or EBP configuration setting rac.class (located in a jar file specified by the file path rac.classpath) indicates this RAC module should be used for authenticating and authorizing resources. If the configuration is not defined the default RAC module will take effect.
Summary
Heirloom Computing online transaction and batch processing components can be configured to use the Java standard JAAS components for authentication of users and authorization to resources as they execute your Elastic COBOL and Elastic PLI programs. The supplied JAAS module, Heirloom Computing RAC can lookup those rules in an associated directory server supplied by your organization. EBP and ETP configuration settings are used to define to RAC the meta-data ("LDAP schema") names as well as the data (users, passwords) within it. Coupled with proper configuration of Transport Security and Platform Security defined within application servers and host operating file file systems assures the same level of protection as can be found on mainframe systems.
Attachments
Attachments referenced within the body of the article are shown below.
0 Comments