WebSphere Application Server on zOS Advanced Configuration by vsb11259

VIEWS: 156 PAGES: 65

									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
            mikeloos@us.ibm.com
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.

								
To top