Slide 1 WebSphere Application Server Advanced Configuration on z/OS Mike Loos IBM SHARE 113, 1145, Application Development & Integration Project Friday, August 28, 2009 8:00 APM firstname.lastname@example.org Slide 2 Washington Systems Center Wildfire Classes WORK SHOP REQUESTED LOCATION SCHEDULED DATE WBSR7 Portland August 18 - 20 Glendale September 9 - 11 Chicago September 15 - 17 Argentine RS October 12 - 15 New York City TBD WSW07 Brazil October 6 - 8 Gaithersburg October 20 - 22 Sacramento November 3 - 5 LINX6 Gaithersburg Dec 8 - 10 WebSphere Application Server for z/OS Version 7.0 - (WBSR7) ZWPS6 Waltham 4Q Columbus Aug 4 - 6 Security Workshop: WebSphere Application Server for z/OS V 7.0(WSW07) ZJAV1 Toronto July 14 & 15 Deploying WebSphere Centric Products on Linux for zSeries - (LINX6) Gaithersburg Sept 22 & 23 z/OS JAVA Exploiters and JAVA Batch Workshop - (ZJAV1) WMB06 Brazil October 14 - 16 WebSphere Process Server V6 for z/OS Implementation Workshop - (ZWPS6) ZPRT1 Olympia, WA TBD WebSphere Message Broker for z/OS Version 6 Workshop - (WMB06) VC001 Columbus Sept 15 - 17 Customizing Linux and the Mainframe for Oracle DB applications – (LXOR6) San Francisco Oct 13 - 15 Toronto Nov 10 - 12 LXOR6 Gaithersburg Sept 29 - Oct 1 Individual course descriptions are on the IBM Field Education at New York City Oct 27 - 29 https://www.ibm.com/servers/eserver/zseries/education/topgun/ WMQ07 San Francisco Aug 11 - 13 Columbus Sept 1 - 3 Dallas Sept 15 - 17 enrollment/esfldedu.nsf/WebCourseTypes?OpenForm Toronto Sept 29 - Oct 1 Gaithersburg Oct 20 - 22 Minneapolis Nov TBD Slide 3 The Plan… • What We’ll Cover, and Why. • Configuration tweaking. • Creating a new server. • Creating an additional managed node. • Creating a Cluster. • Some Security Info. • Some References and Websites. • Q & A? Slide 4 The Plan… • What We’ll Cover, and Why. • Configuration tweaking. • Creating a new server. • Creating an additional managed node. • Creating a Cluster. • Some Security Info. • Some References and Websites. • Q & A? Slide 5 Configuration tweaking… • Console preferences. One of the first things you may want to do when you first log on to the adminconsole is set your default console preferences. These tend to be individual preferences and I’m showing how I like them set. Your selections may of course vary… You set them by logging on to the adminconsole, and navigating to: Systems administration >> Console Preferences I suggest setting the Synchronize changes with Nodes on, and also like to have the command assistance notifications enabled. You may also consider turning on the Log command assistance commands option. Slide 6 Configuration tweaking… • Time zone(s). • Trace. • Application level. The default for timestamps is for all of them to appear in GMT. Many installations would prefer to have the timestamps appear in local time. There are three variables which you may alter to change the behavior to match your desires. They are: DAEMON_ras_time_local ras_time_local And TZ DAEMON_ras_time_local and ras_time_local are set to 0 (GMT) by default. Actually the variables do not even exist. If you wish to change them, you have to add them and change their value to 1 (local). The TZ variable also does not exist, and in its absence, all application time will be in GMT. This variable can be set to one of the standard timezone values, such as CST6CDT or EST5EDT or whatever is appropriate for your installation. All of these variables are set by logging on to the adminconsole and navigating to the Environment >> WebSphere variables >> and adding them. I would suggest setting them at the cell scope and if you need to vary from that for a particular server you can add another instance at that server’s level. Then save the config and synchronize and the next time a component is started it will take effect. Slide 7 Configuration tweaking… • Message Routing. • Procs are “pre-loaded” with proper DDNAMES • Addition of environment variables. Techdoc: TD103695 Managing Operator Message Routing in WebSphere for z/OS Servers http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103695 As delivered, many messages are routed to the system log via a WTO. They also appear in the JESMSGLG and JESYSMSG DDs for the started tasks. The volume of messages on the syslog and coming across the console is annoying (to say the least). Fortunately it is a simple matter to change this behavior. The routing of these messages is controlled by the following variables: DAEMON_ras_default_msg_dd DAEMON_ras_hardcopy_msg_dd ras_default_msg_dd ras_hardcopy_msg_dd These variables may be set to the DDNAME that you wish to have them routed to and they will no longer be issued as a WTO. Again, the suggestion is to set them at the cell level and then if you need to change them on a finer grained level you can do so by adding a copy of the variable at a “lower” scope. The variables are set by logging on to the adminconsole and navigating to the Environment >> WebSphere variables >> and adding them. Then save, synchronize, and as each component is restarted, the change will take effect. The techdoc describes additional controls that may be added that apply to JES2 systems. Slide 8 Configuration tweaking… • An alternative to all of the editing… • A script! initsetvarsv7.py Script is available at the following URL: http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100963 If you are adverse to doing all of that manual editing, or if you create a lot of cells and wish to make them all look alike, a script might be a good alternative to doing all of the manual edits. The script I am showing, initsetvarsv7.py is a jython script which does all of the changes we made in the adminconsole (with the exception of the console preferences, since they are “per userid”). Slide 9 The Plan… • What We’ll Cover, and Why. • Configuration tweaking. • Creating a new server. • Creating an additional managed node. • Creating a Cluster. • Some Security Info. • Some References and Websites. • Q & A? Slide 10 Creating a new server • Create a new server… To create a new server. Click on Servers >> New Server, select the server type (the default of WebSphere Application Server is what we want for this exercise), and click on Next. Slide 11 Creating a new server Select the proper node from the dropdown box (we only have one at this point so it is an easy decision) and specify the new server name. Then click on Next. Slide 12 Creating a new server Select a template (the only one available at this point is the default template). Click Next. Uncheck the “Generate Unique Ports” box, specify the Server Short names (Specific and Generic), and if you don’t want to run in 64 bit mode (which is the V7 default) uncheck the box. We’ll leave it checked. Click Next. Slide 13 Creating a new server You will next be presented with a confirmation panel. Click on Finish. Then click on your new server. Slide 14 Creating a new server On the next screen, locate the section for Ports and click on Ports. You will be presented with a screen listing all of the ports for the server. You now need to set each port to the proper number based on your numbering scheme. You may also have to add some additional host alias entries to the default virtual host for the http ports. You may then click on Save, and synchronize and your new server is ready to start. Slide 15 Creating a new server • As an alternative to setting the ports manually… • A script! updNewServerv7.py As an alternative to setting the ports manually, you may wish to create and run a script to set them all manually after the server had been saved and the configuration synchronized. The script shown uses the WSC Naming convention, but could easily be adapted to other naming and numbering conventions… As an added benefit, it adds the necessary virtual host host alias entries as well. Slide 16 Creating a new server • And if you really want to avoid the adminconsole… createNewServerv7.py As an alternative to creating the server manually, you can run a script to do the entire process. The script shown requires that you tell it as arguments the servername, the nodename, and the originating (or low) port for the server. If you were using the WSC naming convention, the script would require no modification as it would properly set the specific and generic server short names and the port specified would be the soap port for the server. Again, if you are using a different naming convention the script should be fairly easy to modify to fit your needs. Slide 17 Creating a new server • Security updates. • Using Generics. • Using non-Generics. • Userids • Controller. • Servant. • Adjunct (optional). • STARTED class profile. • CBIND class profiles. • SERVER class profiles. • Keyrings and certificates. Security profiles may need to be updated. If you have defined a generic set of RACF definitions which will cover these new servers, you may not need to change anything at this point. In a cell where the RACF definitions are generic, it is common to use one USERID for all controllers and one for all servants and adjuncts. In this case the keyring and certificate that is defined for those USERIDs will suffice. However, if you used the default RACF definitions, which are specific (not generic), as provided by the BBOWBRAK Rexx exec in the generated .DATA file, you will need to add the following: New USERID for each of the address spaces (controller, servant, and optionally adjunct). STARTED profile for the new server controller, servant, and optionally the adjunct regions CBIND and SERVER classes profiles to include the new Cluster Transition Name and the new server Keyrings for the controller and servant (and possibly adjunct) regions, and new certificate for the controller (and possibly adjunct), and connect the CERTAUTH certificate to the keyrings. Slide 18 The Plan… • What We’ll Cover, and Why. • Configuration tweaking. • Creating a new server. • Creating an additional managed node. • Creating a Cluster. • Some Security Info. • Some References and Websites. • Q & A? Slide 19 Creating an additional Managed Node • Using the Configuration spreadsheet. • Using the zPMT (WCT). • Running the generated jobs. Creating the additional Managed Node involves basically three major steps, each with a few “substeps”. First (if it is being used) the information from the configuration spreadsheet must be extracted. Then the zPMT (WCT) must be run and the output (generated jobs) must be uploaded to the target system. Then the generated jobs need to be run in accordance with the generated instructions. Slide 20 Creating an additional Managed Node • Using the spreadsheet. • SHARE S1 Configuration.xls • Using the zPMT. • Start the WCT. • Etc… The spreadsheet provides a starting point for the PMT, i.e. a responsefile so that you don’t have to enter all values manually. When starting the WCT, you’ll need to choose a “location” for your definitions. Use a path that is indicative of what you are doing. A possible suggestion would be: drive:\WCT Workspace\cellname. Then when you create your customization definitions for that location, you can choose names for them that further define what you are doing: dmgr, emptynode, etc. The order in which you create the jobs with the PMT is not particularly important, but it seems to work well to start with the Deployment Manager, then create an Empty Managed node, then to add servers either with scripting or the AdminConsole. Since we are working with an existing cell and adding an additional empty node, well be adding a definition to an existing location. The Location used to create the jobs for the cell (s1cell) used for this example were: Location Name: SHARE S1Cell Location Path: D:\WAS V7 WCT Workspaces\s1cell The customization definitions that were created previously were: Deployment Manger: s1dmgr st 1 Empty Managed Node: s1emptyc Now we’ll be adding: st 1 Empty Managed Node: s1emptyd Slide 21 Creating an additional Managed Node • For this section of the PMT (Empty Managed Node): • Load the correct “response file”. • Step through the panels. • Make any changes that seem necessary. • Create the jobs. • Upload the jobs. If you are using the zPMT version of the spreadsheet shown earlier, you will have created “response files”. For each section (dmgr, empty managed node), you will need to specify the created response file in the zPMT. Slide 22 Using “Simplified RACF definitions… • Two Jobs in the .CNTL datasets run a REXX Exec in the .DATA datasets. • BBOSBRAK BBOSBRAC • BBOMBRAK BBOMBRAC • The two REXX execs may be modified or replaced. • We used a set of modifications when this cell was originally created, illustrated here. • BBOMBRAK DORAC700 • Some documentation on the modifications… • Using Generic RACF Profiles with WebSphere on z/OS V7 • http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101427 This all assumes the use of RACF for the security product. If you are an ACF2 or Top Secret installation, then you definitely need to make significant changes. If you are NOT using simplified RACF definitions, then nothing needs changing. There is an alternate template on the techdoc site that provides a full set of RACF definitions if you are using the naming convention supported by the spreadsheet and prefer the simplified generic RACF definitions. Simply copy the template into the .DATA dataset using a new member name, and modify it, either according to the comments at the beginning of the template or in conjunction with the edit macro provided as part of the same techdoc. Then modify the BBOMBRAK member of the .CNTL dataset to point to the new member of the .DATA dataset and run the job. There is no need to run any other RACF jobs after that point. Slide 23 Creating an additional Managed Node • Read the instructions. • Generated instructions Clicking on View allows you to look at or print the generated instructions. Slide 24 Creating an additional Managed Node • Running the generated JOBs. • BBOMCPY1 • BBOMCFS • BBOMHFSA • BBOWWPFM Note the lack of any security related jobs… • BBOWMNAN • Start the nodeagent. We’ll go into the security stuff in more detail further on in this presentation. Slide 25 The Plan… • What We’ll Cover, and Why. • Configuration tweaking. • Creating a new server. • Creating an additional managed node. • Creating a Cluster. • Some Security Info. • Some References and Websites. • Q & A? Slide 26 Creating a cluster • What is a cluster? Artifact Name Comment Cell s1cell Existing Node on SYSC s1nodec Existing Node on SYSD s1noded Existing, Federated, Empty Cluster s2sr03 To be created Server on SYSC s1sr03c Existing Server on SYSD s1sr03d To be created A cluster, in its most simple form is a server. And every server is a cluster. But a cluster composed of a single server isn’t of much interest. Usually when discussing a cluster, we are talking about a cluster containing two or more servers, generally in more than one node. Creation of a cluster can start with zero, or one servers or templates. A cluster can never be created from more than one server. Our starting point for this exercise is the table shown. We have created so far in this presentation a multinode, mutisystem cell. The cell is the s1cell, and we have a node s1nodec on SYSC and a node s1noded on SYSD (which we have just created). The s1nodec has a server s1sr03c (also recently created). We will create a cluster s1sr03 that will consist of s1sr03c which will be converted into a cluster member, and we will add one additional member s1sr03d in node s1noded. Slide 27 Creating a cluster As always, we start by logging on to the adminconsole. Then we navigate to Servers >> Clusters >> WebSphere application server clusters and then click New. Slide 28 Creating a cluster You’ll see a screen similar to the one shown where you can fill in the values for Cluster name and cluster Short name. Then click Next. Slide 29 Creating a cluster Now we’re ready to create the first cluster member. We’re going to go the route of creating the member by converting an existing application server. As soon as we select that option, many of the other fields “grey out”. We select s1sr03c in node s1nodec from the drop down box after checking the radio button. Then click Next. Slide 30 Creating a cluster This is the next screen you’ll see. Fill in the member name of the new cluster member (the one that doesn’t yet exist), s1sr03d, select the appropriate node from the drop down box, in this case s1noded, and fill in the short name, S1SR03D in our example. Uncheck the Generate unique http ports (in most cases). Then click on Add Member Slide 31 Creating a cluster You’ll be presented with a panel similar to this one. You’ll notice that there is an additional cluster member in the table at the bottom of the panel. You now have an opportunity to add additional cluster members, simply by filling in the blanks as we did on the previous screen and clicking on add member. Two members is enough for our example, so we’ll simply click on Next. Slide 32 Creating a cluster You’ll see a summary page describing the to be created cluster. All you need to do is to click on Finish. Slide 33 Creating a cluster Simply Save and synchronize and you’ve created the cluster. You may have to update the Host Aliases for the Virtual Host. If you have been using an asterisk(*) for the host name on the original server, this will not be necessary. All that remains is to start the cluster members (servers) and verify that they start and run properly. Slide 34 Creating a cluster • A script? • s4id = AdminConfig.getid('/Server:s1sr04c/') • c4id = AdminConfig.convertToCluster(s4id, 's1sr04') • AdminTask.createClusterMember('[-clusterName s1sr04 - memberConfig [-memberNode s1noded -memberName s1sr04d -memberWeight 2 -genUniquePorts false - specificShortName S1SR04D]]') • wsadmin>AdminConfig.save() If you’d rather create your cluster using a script, here are the commands (bare bones) that you’d need. The first gets the id of the server you choose to convert to a cluster. The second converts the server with long name s1sr04c to a cluster with cluster name of s1sr04 with a single member named s1sr04c You’re essentially done at this point, but since the main reason for a cluster is to have two or more members… The third command will create a new cluster member in cluster s1sr04 with member name (long name) of s1sr04d on node s1noded with a shortname of S1SR04D. This command also leaves the ports alone. You’ll have to do something about that later. The last command saves the configuration. Simple? Yes! Now you should probably update the port assignments of the new cluster member, possibly using the previously mentioned script updNewServer.py. You may have to update the Host Aliases for the Virtual Host. If you have been using an asterisk(*) for the host name on the original server, this will not be necessary. All that remains is to start the cluster members (servers) and verify that they start and run properly. Slide 35 The Plan… • What We’ll Cover, and Why. • Configuration tweaking. • Creating a new server. • Creating an additional managed node. • Creating a Cluster. • Some Security Info. • Some References and Websites. • Q & A? Slide 36 Security Info • Groups. • Users. • Connections. • CBIND Class. • SERVER Class. • STARTED Class. • EJBROLE Class. • Administrative. • Naming. • APPL Class. • FACILITY Class. • Digital Certificate Work. • Miscellaneous. By default, the WebSphere dialogs or zPMT generate RACF Profiles in a mixture of discrete and generic form. For instance: The RACF profiles could be created such that there would be a one to one correspondence between RACF userids and server components. In fact, in previous releases of WebSphere on z/OS this was how the RACF jobs set things up. In the current release however, the reality is somewhere between a complete one to one and a completely generic solution With the “reduced” RACF generation option of the spreadsheet, combined with some replacement the generated EXECs, the userid count can be reduced to five: The administrative userid, the guest userid, the asynchronous administrative task userid, the controller userid, and the servant userid. Similar reductions can be made in most of the other classes. The following slides show profiles of various types that are created when the reduced generation is used (in conjunction with the replacement EXEC). Why is this a good thing? Well, it doesn’t appreciably decrease the level of security on the environment, it reduces the amount of administration, and the most useful result is that once it is set up initially for a cell, there is rarely a need to modify or add profiles as the environment grows (additional clusters, servers, nodes, etc.), which is why we’re discussing it in this presentation. Slide 37 Security Info • Groups. • Config group: xxCFG • Servant Group: xxSRVG • Guest Group: xxGUESTG • Commands. • "ADDGROUP xxCFG OMVS(GID(nnnnn0))" • "ADDGROUP xxSRVG OMVS(GID(nnnnn1))" • "ADDGROUP xxGUESTG OMVS(GID(nnnnn2))" The default and the generic groups are the same. No modification is necessary. It could be argued that the Servant Group could be collapsed into the Config group, but based on the connections shown on a subsequent page, it really isn’t necessary. The commands are as shown. "ADDGROUP xxCFG OMVS(GID(nnnnn0))" "ADDGROUP xxSRVG OMVS(GID(nnnnn1))" "ADDGROUP xxGUESTG OMVS(GID(nnnnn2))" Slide 38 Security Info • Users. • Admin user: xxADMIN • Guest user: xxGUEST • Controller User: xxACRU • Servant User: xxASRU • Asynchronous Administrative task User: xxADMSH This is the reduced user set. The controller userid will be used for all controllers (daemon, dmgr, appservers, nodeagents). The servant userid will be used for all adjuncts and servant address spaces. The commands will no longer be shown on the screens, but are included for completeness in the speaker notes… "ADDUSER XXADMIN DFLTGRP(XXCFG) OMVS(UID(nnnn1) HOME(/wasv7config/xx" || , "cell/home/XXCFG) PROGRAM(/bin/sh)) NAME('WAS ADMINISTRATOR') NOPASS" || , "WORD NOOIDCARD" "ADDUSER XXGUEST RESTRICTED DFLTGRP(XXGUESTG) OMVS(UID(nnnn2) HOME(/" || , "wasv7config/xxcell/home/XXGUESTG) PROGRAM(/bin/sh)) NAME('WAS DEFAU" || , "LT USER') NOPASSWORD NOOIDCARD" "ADDUSER XXACRU DFLTGRP(XXCFG) OMVS(UID(nnnn3) HOME(/wasv7config/xxc" || , "ell/home/XXCFG) PROGRAM(/bin/sh)) NAME('WAS CR') NOPASSWORD NO" || , "OIDCARD" "ADDUSER XXASRU DFLTGRP(XXSRVG) OMVS(UID(nnnn4) HOME(/wasv7config/xxc" || , "ell/home/XXSRVG) PROGRAM(/bin/sh)) NAME('WAS SR') NOPASSWORD NO" || , "OIDCARD" "ADDUSER XXADMSH DFLTGRP(XXCFG) OMVS(UID(nnnn5) HOME(/wasv7config/xx" || , "cell/home/XXCFG) PROGRAM(/bin/sh)) NAME('WAS Asynch Admin Task') N" || , "OPASSWORD NOOIDCARD" Slide 39 Security Info • Connections. • Servant User to Config Group • Other Users to Config Group The generated REXX execs will connect the servant userid to the config group, but this may be a good time to connect other users (yourself and other full administrators). Commands: "CONNECT XXASRU group(XXCFG)" "CONNECT (Yourids) GROUP(XXCFG)" Slide 40 Security Info • CBIND Class. • Cluster access: CB.BIND.SAF_profile_prefix_name.cluster_name • Application access: CB.SAF_profile_prefix_name.cluster_name The CBIND class is used to control access by clients to clusters. An access level of READ is sufficient for simple access. If the SAF_profile_prefix is not defined when the configuration is built, then that level is left out. The first form: CB.BIND.SAF_profile_prefix_name.cluster_name is used to control access by local and remote clients to the cluster. Read access is required by local or remote clients that wish to access the cluster. Control access to this profile is required if the process is to be trusted to assert identities to WebSphere Application Server. This is primarily intended for intermediate servers which have already authenticated their clients, for example a webserver. The second form: CB.SAF_profile_prefix_name.cluster_name is used control access to J2EE applications within the cluster. Read access is required by any client that wishes to access a J2EE application running in a server which is a member of the cluster. Commands: "RDEFINE CBIND CB.BIND.XX* UACC(READ)" "RDEFINE CBIND CB.XX* UACC(READ)" "PERMIT CB.BIND.XX* CLASS(CBIND) ID(XXCFG) ACCESS(CONTROL) " "PERMIT CB.XX* CLASS(CBIND) ID(XXCFG) ACCESS(READ) " Slide 41 Security Info • SERVER Class. • Dynamic Application Environments: CB.servershortname.genericshortname.cellshortname The SERVER class profiles are used to control access to controller services by the servant (which is running without APF authorization), and to access WLM application environment services. For environments using dynamic WLM application environments (which WebSphere V7 does) the profile is formed as: CB.servershortname.genericshortname.cellshortname Read access is required. Commands: "RDEFINE SERVER CB.*.XX*.* UACC(NONE) " "PERMIT CB.*.XX*.* CLASS(SERVER) ID(XXCFG) ACC(READ)" Slide 42 Security Info • STARTED Class. • xxDEMN*.* Any daemon stc; Userid = xxACRU, Group = xxCFG • xxDCR.* Deployment manager controller: Userid = xxACRU, Group = xxCFG • xxACR*.* All other Controllers: Userid = xxACRU, Group = xxCFG • xx*.* All servant (and adjunct) stcs. Userid = xxASRU, Group = xxCFG • xxADMSH.* Asynch Admin Task STC. Userid = xxACRU, Group = xxCFG The STARTED class profiles are used to determine which userid/group is assigned to the WebSphere started tasks (STCs). STCs get “started” in two different ways. The first is the “normal” way with a START command, and the second is an internal method used (at least here) by the WLM. These require two different types of profiles. The profiles for everything but the servant address spaces, which are started with START commands, are of the form PROCNAME.JOBNAME (we use a genericized version of the PROCNAME and an * to indicate any JOBNAME started with that proc). The profile for the servant address spaces which are started with an ASCRE macro by WLM are of the form JOBNAME.JOBNAME . As you can see by examining the profile names, the servant profile will only be “hit” if the search falls through all of the more specific profiles, of which there should be one for each proc except the servant proc. Commands: "RDEFINE STARTED XXDEMN*.* STDATA(USER(XXACRU) GROUP(XXCFG) TRACE(YES))" "RDEFINE STARTED XXDCR.* STDATA(USER(XXACRU) GROUP(XXCFG) TRACE(YES))" "RDEFINE STARTED XXACR*.* STDATA(USER(XXACRU) GROUP(XXCFG) TRACE(YES))" "RDEFINE STARTED XX*.* STDATA(USER(XXASRU) GROUP(XXCFG) TRACE(YES))" "RDEFINE STARTED XXADMSH.* STDATA(USER(XXADMSH) GROUP(XXCFG) TRACE(YES))" Slide 43 Security Info • EJBROLE Class. • Administrative. • Administrator XXCELL.administrator • Monitor XXCELL.monitor • Configurator XXCELL.configurator • Operator XXCELL.operator • Deployer XXCELL.deployer • Adminsecuritymanager XXCELL.adminsecuritymanager • scaAllAuthorizedUsers XXCELL.scaAllAuthorizedUsers • Naming. • CosNamingRead XXCELL.CosNamingRead • CosNamingWrite XXCELL.CosNamingWrite • CosNamingCreate XXCELL.CosNamingCreate • CosNamingDelete XXCELL.CosNamingDelete The EJBROLE class is used to control access to roles. The Administrative roles are for access to functions in the adminconsole and the wsadmin scripting interface. The Naming roles are for access to the JNDI namespace. The XXCELL in the role names corresponds to the SAF profile prefix. If a cell is defined without a SAF profile prefix, then the EJBROLE profiles must be created without the prefix. This is NOT a good practice, since in that case if there are multiple cells within the plex, the profiles would cover all cells for which there is no SAF profile prefix specified. Use of this “prefix” allows for granularity at least at the cell level. There are other roles possible (and probable) which are defined by the deployer of an application. We’re not showing them here, but they follow the same rules. As you can see from the PERMIT commands, READ access is sufficient to grant access to a role. Commands: "RDEFINE EJBROLE XXCELL.administrator UACC(NONE)" "RDEFINE EJBROLE XXCELL.monitor UACC(NONE)" "RDEFINE EJBROLE XXCELL.deployer UACC(NONE)" "RDEFINE EJBROLE XXCELL.configurator UACC(NONE)" "RDEFINE EJBROLE XXCELL.operator UACC(NONE)" "RDEFINE EJBROLE XXCELL.adminsecuritymanager UACC(NONE)" "RDEFINE EJBROLE XXCELL.auditor UACC(NONE)" "RDEFINE EJBROLE XXCELL.scaAllAuthorizedUsers UACC(READ)" "PERMIT XXCELL.adminsecuritymanager CLASS(EJBROLE) ID(XXADMIN) ACCESS(READ)" "PERMIT XXCELL.administrator CLASS(EJBROLE) ID(XXCFG) ACCESS(READ)" "PERMIT XXCELL.auditor CLASS(EJBROLE) ID(XXCFG) ACCESS(READ)" /* Do EJBROLE Naming stuff */ say 'Defining and Permitting EJBROLE Naming profiles...' say ' ' "RDEFINE EJBROLE XXCELL.CosNamingRead UACC(READ)" "PERMIT XXCELL.CosNamingRead CLASS(EJBROLE) ID(XXGUEST) ACCESS(READ)" "RDEFINE EJBROLE XXCELL.CosNamingWrite UACC(NONE)" "RDEFINE EJBROLE XXCELL.CosNamingCreate UACC(NONE)" "RDEFINE EJBROLE XXCELL.CosNamingDelete UACC(NONE)" "PERMIT XXCELL.CosNamingWrite CLASS(EJBROLE) ID(XXCFG) ACCESS(READ)" "PERMIT XXCELL.CosNamingCreate CLASS(EJBROLE) ID(XXCFG) ACCESS(READ)" "PERMIT XXCELL.CosNamingDelete CLASS(EJBROLE) ID(XXCFG) ACCESS(READ)" Slide 44 Security Info • APPL Class. • SAF Profile Prefix specified XXCELL • Not specified CBS390 The APPL Class profile controls whether an authenticated user can access any application in a cell. If a SAF profile prefix has been specified, it will be the APPL Class profile name. If not, the profile name will be CBS390. You’ll notice the PERMIT with READ access for the xxGUEST ID. The guest id (also, and more correctly known as the unauthenticated userid) is an ID defined with the RESTRICTED attribute. Restricted userids have no access via the UACC (Universal Access) level, so it must be specifically added with READ access. The guest id is the one used to access an application before it has gone through authentication. This is similar to the concept of a CICS default userid, if you are familiar with that term. An example would be access to a logon screen. The default jobs will define the APPL class to be the same as the SAF profile prefix and permit the config group and guest user READ access. The alternative script does the same, but adds a permit of all defined users with READ access. Commands: "RDEFINE APPL XXCELL UACC(NONE) " "PERMIT XXCELL CLASS(APPL) ID(XXCFG) ACCESS(READ)" "PERMIT XXCELL CLASS(APPL) ID(XXGUEST) ACCESS(READ)" "PERMIT XXCELL CLASS(APPL) ID(*) ACCESS(READ)" Slide 45 Security Info • FACILITY Class. • WLM Services BPX.WLMSERVER • Digital Certificate List IRR.DIGTCERT.LIST • Digital Certificate List Ring IRR.DIGTCERT.LISTRING • Sync to Thread BBO.SYNC.xx*.** • Trusted Applications BBO.TRUSTEDAPPS.xx*.** The FACILITY class tends to be a “catch all” class for profiles that protect various functions in the operating system. Access to the BPX.WLMSERVER profile allows servants to access WLM services (normally reserved to APF authorized users). Access to the two DIGTCERT profiles allows access to certificates and keyrings. Access to the BBO.SYNC.xxCELL*.** profile is as follows: If the controller does not have access to the profile, the Synch to OS Thread Allowed capability will be disabled. If the controller has READ access to the profile, the Synch to OS Thread Allowed capability may be used, but is limited to security environments for which a SURROGATE class profile of the form BBO.SYNC.userid exists and the controller has access to the profile. The userid(s) specified as part of the SURROGAT class profile are the only ones for which the servant will be allowed to establish a security environment. If the controller has CONTROL access to the profile, the SURROGAT class check will not be made and the servant will be allowed to build a security environment for any user. Access to the BBO.TRUSTEDAPPS.xxCELL*.** profile with READ access for the controller allows the server to be treated as “trusted”, and therefore to call certain authorized functions. An example is the deployment manager needs the capability to check security credentials when a user logs on and to switch the SAF identity (userid) on the executing thread. Commands: "PERMIT BPX.WLMSERVER ACCESS(READ) ID(XXCFG) CL(FACILITY)" "PERMIT IRR.DIGTCERT.LIST ACCESS(READ) ID(XXCFG) CL(FACILITY)" "PERMIT IRR.DIGTCERT.LISTRING ACCESS(READ) ID(XXCFG) CL(FACILITY)" "RDEFINE FACILITY BBO.SYNC.XX*.** UACC(NONE)" "RDEFINE FACILITY BBO.TRUSTEDAPPS.XX*.** UACC(NONE)" "PERMIT BBO.TRUSTEDAPPS.XX*.** CLASS(FACILITY) ID(XXCFG) ACCESS(READ)" Slide 46 Security Info • Digital Certificate Work. • CERTAUTH Certificate. • Personal Certificate for the Controller ID. • Keyrings. • Controller userid. CERTAUTH and Personal certificate. • Servant userid. CERTAUTH • Admin userid. CERTAUTH • Admin Shell userid. CERTAUTH The digital certificates are used to establish an SSL or JSSE connection between two endpoints, for example a browser and an application. The normal setup for a cell creates a CERTAUTH cert. The CERTAUTH cert is then used to sign the Personal Certificate that is attached to the controller userid. Keyrings are created for each of the indicated userids and the shown certificates are connected to the keyrings. The keyring name is dictated by the ring name specified in the SSL configuration. Commands: CERTAUTH Certificate "RACDCERT CERTAUTH GENCERT SUBJECTSDN(CN('WAS CertAuth for Security D" || , "omain') OU('XXCELL')) WITHLABEL('WebSphereCA.XXCELL') TRUST NOTAFT" || , "ER(DATE(2020/12/31))" "SETROPTS RACLIST(FACILITY) REFRESH“ Personal Certificate "RACDCERT ID (XXACRU) GENCERT SUBJECTSDN(CN('your.url'" || , ") O('IBM') OU('XXCELL')) WITHLABEL('DefaultWASCert.XXCELL') SIGN" || , "WITH(CERTAUTH LABEL('WebSphereCA.XXCELL')) NOTAFTER(DATE(2020/12/31)" || , ")“ Digital Certificate Keyrings and Connections Controller User "RACDCERT ADDRING(WASKeyring.XXCELL) ID( XXACRU )" "RACDCERT ADDRING(WASKeyring.XXCELL.Root) ID( XXACRU )" "RACDCERT ADDRING(WASKeyring.XXCELL.Signers) ID( XXACRU )" "RACDCERT ID(XXACRU) CONNECT (LABEL('DefaultWASCert.XXCELL') RING" || , "(WASKeyring.XXCELL ) DEFAULT)" "RACDCERT ID(XXACRU) CONNECT (RING(WASKeyring.XXCELL) " || , "LABEL('WebSphereCA.XXCELL') CERTAUTH)" "RACDCERT ID(XXACRU) CONNECT (RING(WASKeyring.XXCELL.Root) " || , "LABEL('WebSphereCA.XXCELL') CERTAUTH)" "RACDCERT ID(XXACRU) CONNECT (RING(WASKeyring.XXCELL.Signers) " || , "LABEL('WebSphereCA.XXCELL') CERTAUTH)“ All other Users "RACDCERT ADDRING(WASKeyring.XXCELL) ID( XXASRU )" "RACDCERT ADDRING(WASKeyring.XXCELL) ID( XXADMIN )" "RACDCERT ADDRING(WASKeyring.XXCELL) ID( XXADMSH )" "RACDCERT ID(XXASRU) CONNECT (RING(WASKeyring.XXCELL) LABEL('WebSphereCA.XX" || , "CELL') CERTAUTH)" "RACDCERT ID(XXADMIN) CONNECT (RING(WASKeyring.XXCELL) LABEL('WebSphereCA.XX" || , "CELL') CERTAUTH)" "RACDCERT ID(XXADMSH) CONNECT (RING(WASKeyring.XXCELL) LABEL('WebSphereCA.XX" || , "CELL') CERTAUTH)" Slide 47 Security Info • Miscellaneous Security Setup. • xxADMIN password. • Set to a known value that will not be expired on first use. • Set it to never expire (optional). • Set up SURROGAT access to the xxADMIN id. • Set up a SERVAUTH profile for TCPIP Port Control. • Set up a properly named keyring for additional user(s) and connect the CERTAUTH certificate to it. • A sample REXX exec to perform generic security setup. • DORAC700 The alternative setup performs several other tasks which the default configuration jobs do not. The admin id password is needed when creating a SOAP connection to the deployment manager during node federation. Surrogate access allows you to submit jobs with the Admin ID without putting the password on the JOB card. The SERVAUTH profile for TCPIP port control enables the use of a PORTRANGE statement rather than individual PORT statements in the TCPPROF dataset. For more information see the Techdoc, ”Using SERVAUTH to Protect TCP Port Usage” WP100673, available at the following address. http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100673 The keyring setup for additional userid(s) is to enable the establishment of SSL connections with IDs other than the Admin ID. Commands: Set Password for xxADMIN "ALTUSER XXADMIN PASSWORD(XXADMIN) NOEXPIRE" "PASSWORD USER(XXADMIN) NOINTERVAL“ Set up Surrogat access for xxADMIN "RDEFINE SURROGAT XXADMIN.* UACC(NONE)" "PERMIT XXADMIN.* CLASS(SURROGAT) ID(yourids) AC(READ)“ Set up SERVAUTH profile for TCPIP Port Control "RDEFINE SERVAUTH EZB.PORTACCESS.*.*.XXCELL UACC(NONE)" "PERMIT EZB.PORTACCESS.*.*.XXCELL CLASS(SERVAUTH) ID(XXCFG) ACCESS(READ)“ Set up keyring for additional users. "RACDCERT ADDRING(WASKeyring.XXCELL) ID( YOURID )" "RACDCERT ID(YOURID) CONNECT (RING(WASKeyring.XXCELL) LABEL('WebSphereCA.XX" || , "CELL') CERTAUTH)" Slide 48 The Plan… • What We’ll Cover, and Why. • Configuration tweaking. • Creating a new server. • Creating an additional managed node. • Creating a Cluster. • Some Security Info. • Some References and Websites. • Q & A? Slide 49 Some useful web sites. • Techdocs. • http://www.ibm.com/support/techdocs • The WebSphere InfoCenter. • http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp • Tricia York Garrett’s presentation on how to use the InfoCenter properly. • Saving time with WebSphere Application Server documentation • http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS3546 • WSC Guidelines for a Healthy WebSphere Runtime on z/OS. • Techdoc TD104172 which has a pointer to nearly every other techdoc that pertains to WebSphere on z/OS. • http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD104172 Slide 50 Q and A.
Pages to are hidden for
"WebSphere Application Server on zOS Advanced Configuration"Please download to view full document