1. 19-11-15 07:11 PM 5864_ER_WHITE.1
WebSphere on z/OS
and RACF Security
Michael Erichsen & Adam Mazhar, CSC
March 2006
2. 19-11-15 07:11 PM 5864_ER_WHITE. 2
Purpose and contents of the Presentation
• It is assumed that mainframe and Java people each on their
side have a much deeper knowledge than the writer of this
presentation
– The ambition is solely to try to translate the two sides to each
other to help better communicate and, consequently, to plan
and execute the necessary work
• The presentation begins at the traditional RACF model and
the normal Java Sign-on Model
– It then shows how the Java model is implemented in RACF
– It finally compares this new model to the traditional CICS
security model
3. 19-11-15 07:11 PM 5864_ER_WHITE. 3
What is RACF?
• RACF means Resource Access Control Facility
• RACF is really just a data base sitting passively, waiting for
someone to ask questions
• RACF stores lists of groups of users, each having a
password and a number of profiles
– Groups can contain groups
• RACF also stores lists of resource classes, each having a
number of profiles and members
• The programming interface to inquire RACF is called SAF
(System Authorization Facility) and consists of a number of
macro calls
– The main macro calls are
• RACROUTE,REQUEST=VERIFY to verify user IDs
• RACROUTE,REQUEST=AUTH to check against access to a
secure profile
4. 19-11-15 07:11 PM 5864_ER_WHITE. 4
Some RACF Class Examples
Default RACF Classes Description
CBIND Controls the client’s ability to bind to the server. With WebSphere we
need to control access to the server
DATASET Access to data sets
DIGTCERT Contains digital certificates and information related to them
DSNR Controls access to DB2 subsystems (CONNECT)
EJBROLE Member class for J2EE authorization roles. The APPLDATA field in
an EJBROLE profile defines the target Java identity when running in
RUNAS ROLE mode
FACILITY Can be used for anything you want
GCICSTRN Grouping class for CICS Transactions
GEJBROLE Grouping class for Enterprise Java Beans authorization roles
MDSNDB MDSNPK MDSNPN MDSNBP MDSNCL
MDSNTS MDSNSG MDSNTB MDSNSM MDSNSC
MDSNUT MDSNUF MDSNSP MDSNJR DSNADM
Default Classes for DB2 External Security. Special classes exist for
Buffer pools, collections, databases, packages, plans, storage groups,
subsystems, tables, table spaces, etc
TCICSTRN CICS Transactions
SERVAUTH Can be used to protect TCP/IP ports
SERVER Used in WebSphere to control whether a server region can call
authorized programs in the control region
5. 19-11-15 07:11 PM 5864_ER_WHITE. 5
Traditional RACF Profiles and Permission Levels
• TCICSTRN profiles typically contain all transactions in an
application or part of an application
– Can be named whatever is appropriate
• DSNR profiles have names of the form
subsystem.environment
– Subsystem is the name of a DB2 subsystem
– Environment denotes the environment like SASS for CICS,
DIST for Distributed, BATCH for batch and some other types of
workload
• User profiles consists of one or more segments:
– A mandatory RACF segment, which holds basic information
like name, password etc.
– Optional segments with system-specific data including CICS,
LANGUAGE and many others
• Groups of users (or single users) are permitted access to a
profile in a class in levels, each of which include lower
levels:
– ALTER, CONTROL, UPDATE. READ, EXECUTE, NONE
6. 19-11-15 07:11 PM 5864_ER_WHITE. 6
Java Security
• Authentication
– Basically checks the user's login name and password and
allows access to step inside the application realm
• Authorization
– Allows access to specific functions of a given application like:
• Screens (for example only a select people might be able to access
Create New Person screen)
• Fields (For example only a select people might be able to see all
fields on a query result screen or Create screen)
• Buttons (For example on a screen where there is an Update and
Delete buttons, only certain people can do Deletes)
• Data (For example cases for a certain region can only be seen by
users of that region, in other words restricting the where clauses of
the queries based on certain key data elements)
7. 19-11-15 07:11 PM 5864_ER_WHITE. 7
EJBROLES
• Roles, as defined by J2EE, are not inherent in the
mainframe security model
• In order to implement J2EE roles, a new class, EJBROLE,
was created
– The name EJBROLE is not adequate, since it is used for J2EE
roles in both EJB’s and Web applications
• When an application deployer uses a role in a component’s
deployment descriptor, the role name must be identical to
the name of an EJBROLE profile
• A security administrator defines EJBROLE profiles and
permits groups of users to the profiles
• In order to be considered as eligible for a role, a user must
be connected to a group that has read access to the
EJBROLE profile
– You can define single users directly to resources, but that often
makes administration very complicated
8. 19-11-15 07:11 PM 5864_ER_WHITE. 8
GEJBROLE
• RACF also supports a grouping class for the EJBROLE
class called GEJBROLE
• Used when you have a need to give access to the same
groups for several roles
• The GEJBROLE grouping class provides a capability not
natively available in other J2EE servers
• Probably practical, but certainly not portable
9. 19-11-15 07:11 PM 5864_ER_WHITE. 9
Downstream Propagation of Userids From
WebSphere
Authorization
isCallerIn Role()
getCallerPrincipal()
Method
Execution
Downstream
Propagation
RunAs=Server
Identity="Caller"
Identity=Server-Identity
RunAs=Caller Identity="Caller"
RunAs=Role(x) Identity=Role(x) mapped to
RACF identity
RunAs is a J2EE option that allows a bean to temporarily run as the
server identity or the identity of a role that the user has
This effectively corresponds to the CICS-DB2 interface definition
AUTHID, which can be SIGNID (CICS Name), USERID, TERM
(terminal id), TXID (Transaction code), or any string
10. 19-11-15 07:11 PM 5864_ER_WHITE. 10
CICS and RACF Security in the 3270 World
11. 19-11-15 07:11 PM 5864_ER_WHITE. 11
Where is all this Stored?
• At sign-on time CICS builds a control block in memory
representing the connection between terminal id and userid
• This connection is kept until sign-off or time-out
• CICS knows that a user is not signed on, when this
connection does not exist in its control blocks
• The resource classes and profiles are stored in a memory
area shared by all systems (CICS’s, WebSphere’s, DB2’s,
TSO users etc)
13. 19-11-15 07:11 PM 5864_ER_WHITE. 13
Where is all this Stored?
• At sign-on time WebSphere creates a cookie containing a
security token, which represents the userid
• WebSphere knows that a user is not signed on, when this
cookie and token is not in the header of a request
• This has been implemented by the WebSphere developers
as a form based authentication
– Necessary features like authentication failures, password
expiration and renewal is implemented as a Servlet Filter
• A servlet filter is equivalent to a user exit in CICS
• The resource classes and profiles are stored in a memory
area shared by all systems (WebSphere’s, CICS’s, DB2’s,
TSO users etc)
14. 19-11-15 07:11 PM 5864_ER_WHITE. 14
EJBROLE Implementation
• Defining a role in RACF
– RDEFINE EJBROLE My.Web.Application.Role UACC(NONE)
• Giving permission to a group of users
– PERMIT My.Web.Application.Role CLASS(EJBROLE)
ID(MYUSERS) ACCESS(READ)
• If the user registry custom property
com.ibm.security.SAF.authorization is set to true, then
EJBROLE profiles are used to authorize J2EE roles
• If the user ID has at least READ access to the defined
EJBROLE profile the user ID is considered to be in Role
• If you want to give access to the same groups for several
roles, you can groups EJBROLE classes in a GEJBROLE
class
15. 19-11-15 07:11 PM 5864_ER_WHITE. 15
Further Reading
• Available online at
www.redbooks.ibm.com/
abstracts/sg246846.html
Editor's Notes
In production systems the authentication message is normally suppressed and a menu screen presented
Default Form-based support - detailed flow
This flow specifies the role of the Security Collaborator and describes the HTTP cookies involved.
1. On the first request, a user issues a GET for a protected resource.
2. The Web container security collaborator of the target WebSphere server identifies the request as protected.
3. The collaborator checks to see if a trust association interceptor has been configured.
4. If no trust association interceptor is configured, it searches the request headers for a security token.
5. Since this is the first time that the user has issued a request, there is no such token. It then searches the deployment descriptor for the type of
authentication specified for this resource, which is found to be “form”. The collaborator searches the configuration for the name of the form to be sent
back to the client. It is at this point that a cookie named WASReqURL is created. This cookie is used to keep track of the client’s original URL request.
6. A redirection to the configured login form is sent to the client, together with the WASReqURL cookie.
7. The client receives the redirection and issues a GET for the form.
8. The client receives the form, completes it and posts to the specified j_security_check action, passing the WASReqURL cookie.
9. The security collaborator obtains the predefined fields from the form and checks with RACF to make sure they are legitimate.
10.If successful, it creates a security token using the server’s configured ICSF key, creates a cookie called ltpa, and puts the token inside of it.
11.The security collaborator also reads the WASReqURL cookie to know where the client wanted to go before the authentication happened and sends a
redirect to the client specifying the URL found in the cookie. After WASReqURL is read, it is discarded.
12.If session affinity is configured, another cookie, JSESSIONID, is created. This cookie has no security information. Its mandate is to provide session routing information to the different WebSphere components to enable the correct routing of subsequent requests during the same client session to the same server region that last fulfilled the request.
13.The client gets the redirect, together with the ltpa cookie (and possible JSESSIONID).
14.The client requests access to the protected resource.
15.The security collaborator sees that it is a protected resource and checks for the existence of the cookie “ltpa” (Lightweight Third Party Authentication ). If it is there, it extracts the token and tries to decrypt it using the Server’s configured ICSF key. If successful it gives access to the wanted resource.
On subsequent requests, as long as the security credentials are valid, only steps 14-15 reoccur.
It should be noted that the ltpa cookie has nothing but the name in common with the Lightweight Third Party Authentication approach commonly found in
WebSphere distributed installations.