websphere on z/os and racf security

Click here to load reader

Post on 18-Jan-2017




2 download

Embed Size (px)


WebSphere and RACF SecurityMarch 2006
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
* 5864_ER_WHITE. *
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=AUTH to check against access to a secure profile
* 5864_ER_WHITE. *
Controls the client’s ability to bind to the server. With WebSphere we need to control access to the server
Member class for J2EE authorization roles. The APPLDATA field in an EJBROLE profile defines the target Java identity when running in RUNAS ROLE mode
Grouping class for Enterprise Java Beans authorization roles
Default Classes for DB2 External Security. Special classes exist for Buffer pools, collections, databases, packages, plans, storage groups, subsystems, tables, table spaces, etc
Used in WebSphere to control whether a server region can call authorized programs in the control region
* 5864_ER_WHITE. *
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:
* 5864_ER_WHITE. *
Basically checks the user's login name and password and allows access to step inside the application realm
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)
* 5864_ER_WHITE. *
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
* 5864_ER_WHITE. *
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
* 5864_ER_WHITE. *
Downstream Propagation of Userids From WebSphere
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
Authorization isCallerIn Role() getCallerPrincipal()
In production systems the authentication message is normally suppressed and a menu screen presented
* 5864_ER_WHITE. *
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)
* 5864_ER_WHITE. *
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.
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
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
* 5864_ER_WHITE. *
Not Signed On

View more