I’ll cover the instructions to install z/OS Connect, but the instructions are similar for other products. The steps are to create the minimum server configuration and gradually add more function to it.
The steps below guide you through
- planning to help you decide what you need to create, and what options you have to choose
- initial customisation and creating a server, creating defaults and creating function specific configuration files, for example a file for SAF
- starting the server
- enable logon security and add SAF definitions
- add keystores for TLS, and client authentication
- adding an API and service application
- protecting the API and service applications
- collecting monitoring data including SMF
- use the MQ sample
- using WLM to classify a service
With each step there are instructions on how to check the work has been successful.
Enable logon security
To enable security checking you need to use the zosconnect_zosConnectManager tag.
<zosconnect_zosConnectManager requireAuth="true" requireSecure="true" setUTF8ResponseEncoding="true"/>
add to the zosconnect.xml or server.xml file.
You cannot do much with this enabled as you need TLS
Add in the SAF repository to use z/OS security services.
Within the server directory create a file called saf.xml. (I always used ISPF 3.17, and use cc…cc create.. to create a new file.
<server> <featureManager> <feature>transportSecurity-1.0</feature> <feature>zosSecurity-1.0</feature> <feature>appSecurity-2.0</feature> </featureManager> <authentication id="Basic" cacheEnabled="false" /> <safAuthorization id="saf-authorization" racRouteLog="ASIS" /> <safRegistry id="saf" realm="myrealm"/> <safCredentials profilePrefix="ZZZZDFLT" suppressAuthFailureMessages="false" unauthenticatedUser="WSGUEST"/> </server>
Where you need to specify the profile prefix (for example ZZZBFLT), and define the security profile.
I do not think the realm is used for SAF processing.
If you are planning on using a new profilePrefix (YYYYDFLT) you will need to create several profiles.
RDEFINE APPL YYYYDFLT UACC(NONE) PERMIT YYYYDFLT CLASS(APPL) ACCESS(READ) ID(group1,group2) SETROPTS raclist(APPL) refresh RDEFINE server BBG.SECPFX.YYYYDFLT uacc(NONE) permit BBG.SECPFX.YYYYDFLT class(server) access(read) id(start1) setropts raclist(server) refresh rdefine ejbrole YYYYDFLT.zos.connect.access.roles.zosConnectAccess uacc(none) permit YYYYDFLT.zos.connect.access.roles.zosConnectAccess class(ejbrole) id(Adcdc) access(READ) permit YYYYDFLT.zos.connect.access.roles.zosConnectAccess class(ejbrole) id(group1,group2) access(READ) setropts raclist(ejbrole) refresh
These profiles are only accessed once someone tries to use the server – not at startup, so try logging on using the https port.
Every one using the server needs read access to YYYYDFLT CLASS(APPL).
As an interim step towards getting your server up and secure, enable userid and password authentication.
<webAppSecurity overrideHttpAuthMethod="BASIC"/> <webAppSecurity allowFailOverToBasicAuth="true"/>
overrideHttpAuthMethod=”BASIC” says used userid and password – and not client certificates.
allowFailOverToBasicAuth=”true” says if the client certificate logon fails – fail over to basic, userid and password.
Once you have configured the server, you can remove the overrideHttpAuthMethod tag, so client certificates are used. Once these are working remove the allowFailOverToBasicAuth, to remove the userid and password option. With these both removed, people will have to use client certificates to authenticate.