Downloaded 25 times
Uploaded byMichael Erichsen
Websphere on z/OS and RACF security
This document discusses security models for WebSphere applications on z/OS and how they integrate with RACF. It begins by providing background on RACF and traditional mainframe security concepts. It then explains the Java security model and how RACF implements J2EE roles using new EJBROLE and GEJBROLE classes. It compares this approach to CICS security and how user IDs are propagated downstream. The document aims to help mainframe and Java practitioners communicate by translating between the different security perspectives.
More Related Content
Similar to Websphere on z/OS and RACF security
![Lect 1 Number systems and base conversions. [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/lect1numbersystemsandbaseconversions-260111134109-67c2d865-thumbnail.jpg?width=640&height=640&fit=bounds)
Websphere on z/OS and RACF security
- 1. 19-11-15 07:11 PM5864_ER_WHITE.1 WebSphere on z/OS and RACF Security Michael Erichsen & Adam Mazhar, CSC March 2006
- 2. 19-11-15 07:11 PM5864_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 PM5864_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 PM5864_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 PM5864_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 PM5864_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 PM5864_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 PM5864_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 PM5864_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 PM5864_ER_WHITE. 10 CICS and RACF Security in the 3270 World
- 11. 19-11-15 07:11 PM5864_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)
- 12. 19-11-15 07:11 PM5864_ER_WHITE. 12 WebSphere and RACF Security
- 13. 19-11-15 07:11 PM5864_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 PM5864_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 PM5864_ER_WHITE. 15 Further Reading • Available online at www.redbooks.ibm.com/ abstracts/sg246846.html
Editor's Notes
- #11 In production systems the authentication message is normally suppressed and a menu screen presented
- #13 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.