WebSphere Application Server on z/os: Configuring the New Fine Grained Security Options for Your Admin Console.

Transcription

1 Slide 1 WebSphere Application Server on z/os: Configuring the New Fine Grained Security Options for Your Admin Console. Mike Loos IBM SHARE 113, 1146, Application Development & Integration Project Wednesday, August 26, :30 PM mikeloos@us.ibm.com

2 Slide 2 WebSphere Sessions at SHARE this week Day Time Session Number Title Location Sunday 15: Unravelling the Alphabet Soup on ISA Korbel 1B Sunday 15: WebSphere Application Server Introduction and Concepts for Beginners Room 703 Sunday 16: WebSphere Customer Welcome (Come meet the developers!) Room 703 Monday 11: WebSphere on z/os I m no longer a dummy but. Room 711 Monday 16: z/os WebSphere Monitoring Tools and Tips Room 711 Tuesday 09: WebSphere Application Server for z/os: Latest Status Room 711 Tuesday 11: Optimized Local Adapters Room 711 Tuesday 13: The Future of WebSphere Application Server on z/os: Open Q and A Korbel 4E Tuesday 16: HIS vs WAS Apache based HTTP Server Comparisons Korbel 4E Wednesday 09: WebSphere App Server z/os: Java OOM Analysis Hands-on Lab Room 607-LAB Wednesday 13: WebSphere Application Server V7.0, What s new for Security Room 711 Wednesday 15: WebSphere for z/osv7: LDAP and Multiple Security Domains Room 711 Wednesday 16: WebSphere Application Server on z/os: Configuring the New Fine Grained Security Options for Your Room 711 Adminconsole Thursday 13: Being Driven to the Extreme by the Digital World? WebSphere Products Help Manage Massive Data Room 711 Thursday 15: Building Business Process Management Room 711 Thursday 16: Top Problems Reported to WebSphere z/os Level 2 Room 711 Friday 08: WebSphere Application Server Advanced Configuration on z/os Korbel 4E Friday 08: WebSphere Application Server and CSIv2 Security Room 711 Friday 09: Introduction to Default Messaging in IBM WebSphere Application Server Korbel 4E Friday 09: WebSphere Application Server Version 7 Flexible Management Functions Room 711 EVERY DAY Look for the WebSphere banner at the evening reception and come say hello! 2

3 Slide 3 Washington Systems Center Wildfire Classes WORK SHOP REQUESTED LOCATION SCHEDULED DATE WBSR7 Portland August Glendale September 9-11 Chicago September Argentine RS October New York City TBD WSW07 Brazil October 6-8 Gaithersburg October Sacramento November 3-5 LINX6 Gaithersburg Dec 8-10 WebSphere Application Server for z/os Version (WBSR7) ZWPS6 Waltham 4Q Columbus Aug 4-6 Security Workshop: WebSphere Application Server for z/os V 7.0(WSW07) Deploying WebSphere Centric Products on Linux for zseries - (LINX6) ZJAV1 Toronto July 14 & 15 Gaithersburg Sept 22 & 23 z/os JAVA Exploiters and JAVA Batch Workshop - (ZJAV1) WMB06 Brazil October 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 Customizing Linux and the Mainframe for Oracle DB applications (LXOR6) San Francisco Oct Toronto Nov Individual course descriptions are on the IBM Field Education at enrollment/esfldedu.nsf/webcoursetypes?openform LXOR6 Gaithersburg Sept 29 - Oct 1 New York City Oct WMQ07 San Francisco Aug Columbus Sept 1-3 Dallas Sept Toronto Sept 29 - Oct 1 Gaithersburg Oct Minneapolis Nov TBD 3

4 Slide 4 How We ll Spend the Hour Introduction. This is it Definition. Explanation. A Couple of Examples. Q and A. 4

5 Slide 5 Why Administrative Security? Recyle my Server DM Node Dmgr CR SR Node AppServer CR SR Recyle my Server Delete my App. Cell AppServer CR SR 5 A reasonable question about administrative security might be why to have it at all. Let s look at a hypothetical cell, with several users. If there is no administrative security on the cell and/or its components, then everyone has access to everything. If everyone were to be very careful, always coordinated with the other users, and never made a typing error, there would be no need. But that s not the world in which we live. It would be very easy for user1, attempting to recycle server1, to accidentally recycle server2, and for user3 to delete the wrong application, or to map the correct application to the wrong server, or unmap it from the correct server. That s why we need administrative security, and also why security at a more granular level than cell wide may be necessary.

6 Slide 6 Fine Grained Security Pre-V6.1. Cell Wide only. V6.1. Cells, Nodes, Clusters, Servers, Applications, Nodegroups WSADMIN Scripting Interface Only V7.0 Same artifacts. Now used by adminconsole also. 6 Understanding fine grained security requires that you have an understanding of how cell wide, or regular security work. The type of security we are discussing here is also referred to as administrative security. This is what controls the authorization to make changes to the WebSphere cell configuration and operational environment rather than the authorization to running applications in the servers. In simple terms, it controls what you can do in the adminconsole, or using the wsadmin scripting interface. Prior to V6.1, the controls were cell wide. Essentially if you had access, you had access to everything in the cell. There was some level control, but no granularity beyond all or nothing. In V6.1, the ability was added to allow access to not only the previous cell wide level, but also to allow access to specific Nodes, Clusters, Servers, Applications, and Nodegroups, and any combination of those artifacts, but only when using the wsadmin scripting interface. The authorization to the adminconsole was still cell wide only.

7 Starting with V7, the same granularity which was applied to the scripting interface in V6.1, was extended to cover the adminconsole. The controls used are the same.

8 Slide 7 Cell Wide Administrative Security Adminconsole and scripting. Roles and Profiles. 7 Let s take a look at what cell wide authorization looks like, both the controls it provides and the roles used (and their associated SAF (RACF) profiles).

9 Slide 8 Cell-Wide Administrative Security DM Node Node All Mine! CR Dmgr SR AppServer CR SR Cell AppServer CR SR 8 A WebSphere Cell is the administrative security domain for WebSphere. The cell is the top level artifact. A cell will consist of one or more nodes. A node is a logical, and sort of physical boundary. A cell can span multiple systems (LPARs) within a sysplex. A node may not span a single system. There can be multiple nodes on a single system within in a particular cell, but the most common arrangement consists of a single application server node on a system for a particular cell. There can be multiple servers in a node. A specific case is the Deployment manager node which consists of a single server, the Deployment Manager server. A typical simple cell would consist of a deployment manager node with a deployment manager server, and a single application server node with one or more application servers. This is what the slide depicts. With cell wide Administrative Security, whatever level of authorization you are granted applies to all artifacts (cell, nodes, nodegroups, clusters, servers, applications), within the cell.

10

11 Slide 9 Controlling Roles SAF_profile_prefix.administrator SAF_profile_prefix.monitor SAF_profile_prefix.configurator SAF_profile_prefix.operator SAF_profile_prefix.deployer SAF_profile_prefix.adminsecuritymanager 9 The various levels of authorization are controlled by granting access to SAF based (RACF) EJBROLE profiles. Each cell has the capability of having a SAF Profile prefix, which allows you to differentiate the roles between cells. If you don t specify and use a SAF profile prefix, then the roles would apply to any number of cells that don t have a prefix. The monitor role allows a user which has access to it to both view the configuration and to view it s operational status. This is the role with the lowest level of privilege. The configurator role allows a user which has access to it to change the configuration. For instance, a user with access to the configurator role may create a resource, map an application server, install and uninstall applications, deploy an application, etc.). The operator role allows a user which has access to it to change the runtime state of components. For instance, start or stop a server or application. The administrator role allows a user which has access to it to do anything which would be allowed by the configurator and operator roles, as well as certain other tasks, which are granted only at this level. Examples would be: Modify the server id and/or password and configure global security and it s components. There are certain tasks having to do with mapping users and groups to administrative roles which are not included with the administrator role unless the user also has access to the adminsecuritymanager role. The adminsecuritymanager role allows a user which has access to it to assign users and groups to administrative user roles and administrative group roles when SAF security is not in use.

12 The deployer role allows a user which has access to it to perform configuration and runtime state changes on applications.

13 Slide 10 Servers 10 User mjloos has full cell wide access to the administrator role for the s1cell. A RACF PERMIT has been done to allow userid mjloos read access to an ejbrole profile named S1CELL.administrator. When user mjloos is logged on to the adminconsole, all artifacts in the cell are visible and able to be changed.

14 Slide 11 Applications. 11 This slide shows that all of the applications in the cell are visible and modifiable by user mjloos. We could show any number of other views in the adminconsole, but these are the two which we will use as examples when we set up fine grained security.

15 Slide 12 Fine Grained Administrative Security Adminconsole and scripting. Roles and Profiles. 12 Okay, now let s take a look at what fine grained authorization looks like, both the controls it provides and the roles used (and their associated SAF (RACF) profiles).

16 Slide 13 Fine-Grained Administrative Security DM Node Node Just what I need...! Dmgr CR SR Cell AppServer CR SR AppServer CR SR group1 13 This is the same WebSphere cell which we saw on an earlier slide. But what if we want to have a user that can only modify a single application that is mapped to a single server. We have to create an Authorization Group (group1) that contains that server and that application. Let s see how we might do this, and how we might control access to that group.

17 Slide 14 Controlling Roles SAF_profile_prefix.group1.administrator SAF_profile_prefix.monitor SAF_profile_prefix. group1.configurator SAF_profile_prefix. group1.operator SAF_profile_prefix. group1.deployer SAF_profile_prefix.adminsecuritymanager Note lack of group identifier in the monitor role 14 You ll notice that we have the same roles here, with the minor addition of a group qualifier, between the SAF profile prefix and the role name. This is how we tie the Authorization group to the actual SAF ejbrole profile. The role names have the same meanings as they do for cell wide authorization. When granting access to cell wide roles, access to the specific role includes access to lower level roles, in particular the monitor role. When granting access to group level roles, access to the cell wide monitor is also required. Otherwise there is no visibility into the adminconsole at all, and the message block shown on the slide will be the result.

18 Slide 15 A word about groups RACF Groups. User1 User2 User5 etc. WebSphere Resource Groups. Server s1sr01c. Server s1sr02c. Application PolicyIVP. etc. 15 RACF has a Group concept that is a collection of users. It is common to connect users to various groups and then permit access to resources (datasets, CICS transactions, ejbroles, etc.) based upon their membership in a group. That way you have the ability to simply connect a user to a particular group and provide them the access that they need to all of the resources to which that group has access. Fine grained security in WebSphere introduces the concept of resource groups. These groups are collections of resources that are the same from the perspective of who has access to them. A particular resource group might contain one or more servers, applications, nodes clusters, and/or nodegroups in any combination.

19 Slide 16 Create a group 16 So, how do we create a group? It turns out that it is rather easy. Once you are logged into the adminconsole (with a userid that has access to the adminsecuritymanager role), you click on the plus sign that opens up the Security section, and then click on the Administrative Authorization Groups link. You ll be presented with a list of the groups available (in this case an empty set). Click on the New button.

20 Slide 17 Add applications 17 You ll be presented with a Configuration General Properties Panel. Fill in the group name (in this case we ve chosen to call our group group1 ). Then you can begin to select resources to add to the group. We open up the Applications section and check the box next to the application which we wish to add to the group, in this case DefaultApplication.

21 Slide 18 Create a group The jython representation of the same command: AdminTask.createAuthorizationGroup('[- authorizationgroupname group1]') 18 If you had decided to do the previous steps in a jython script to be run with the wsadmin tool, this is what the scripting command would look like.

22 Slide 19 Add applications The jython representation of the same command: AdminTask.addResourceToAuthorizationGroup(' [-authorizationgroupname group1 - resourcename Application=DefaultApplication]') 19 And this is the command to add the application DefaultApplication to the group, group1.

23 Slide 20 Add Servers 20 Now let s add a server to group1. Simply open up the Nodes section (remember that servers are contained within Nodes), then open up the Servers section. Then put a check in the box next to the server you want to add to the group, in our case s1sr01c. Then click the OK button, save and synchronize. That s it!

24 Slide 21 Add Servers The jython representation of the same command: AdminTask.addResourceToAuthorizationGroup(' [-authorizationgroupname group1 - resourcename Server=s1sr01c]') 21 If you had decided to do the previous steps in a jython script to be run with the wsadmin tool, this is what the scripting command would look like.

25 Slide 22 Finishing up 22 Here is the familiar Save and Synchronize screen

26 Slide 23 Now for the SAF profiles. 23 Finally, you now need to perform the SAF (RACF) work to protect the new group and its authorizations with EJBROLE profiles. The first command adds the ejbrole profile for the administrator role for the new authorization group, group1. You can see how the role is built. The first qualifier is the SAF profile prefix for the cell, which ties this role to the S1CELL. The second qualifier is the name of the authorization group which we just created, group1. And the final qualifier is the actual role name, administrator. Please notice that these roles are in mixed case. The case is important and if it doesn t match the actual casing of the prefix, group, and role, it won t work. The second command permits the user, mjloos2, access to the newly created role. This will allow user mjloos to have administrator access to the server, s1sr01c, and the application, DefaultApplication. The third command permits the user, mjloos2, access to the cell wide monitor role. It turns out, that due to the way the adminconsole works, if the user doesn t have monitor access at the cell level, the user will not be able to see anything in the adminconsole. And to administer it, you need to be able to find and see it first. The final command is the command which refreshes the in storage copies of the ejbrole profiles, so that the Deployment Manager task which is running the adminconsole application, will have access to them.

27 We re now ready to test.

28 Slide 24 Servers 24 The first thing we do is logon to the adminconsole with the id, mjloos2. Then we click on WebSphere Application Servers, which will present a list of servers in the cell. As you can see, they are now divided into two groups, one of which we can administer, and the other of which we can only look at. Step 1 seems to work.

29 Slide 25 Applications 25 Next we click on WebSphere enterprise applications. Again, we see the same two groups, just as we had expected. This looks like success to me!

30 Slide 26 Create another group 26 Let s create another group. This is done just like the first one. Click on Security, then Administrative Authorization Groups, then New.

31 Slide 27 Add a node 27 You ll be presented with a Configuration General Properties Panel. Fill in the group name (in this case we ve chosen to call our group group2 ). Then you can begin to select resources to add to the group. We open up the Nodes section and check the box next to the Node which we wish to add to the group, in this case s1nodec.

32 Slide 28 Finishing up 28 Here is the familiar Save and Synchronize screen

33 Slide 29 Now for the SAF profiles. 29 Let s just do the first part of this and see what the adminconsole will look like. This command permits the user, mjloos3, access to the cell wide monitor role. You ll remember from earlier, that due to the way the adminconsole works, if the user doesn t have monitor access at the cell level, the user will not be able to see anything in the adminconsole. And to administer it, you need to be able to find and see it first. The second command is the command which refreshes the in storage copies of the ejbrole profiles, so that the Deployment Manager task which is running the adminconsole application, will have access to them. We re now ready to test.

34 Slide 30 So far so good 30

35 Slide 31 We can see all of the servers in the cell 31

36 Slide 32 All of the applications 32

37 Slide 33 And all of the nodes 33 This is what we would expect. But notice that all we can do is monitor the various artifacts. We have not yet granted any administrative authority.

38 Slide 34 The rest of the SAF work 34 This should complete the RACF (SAF) work necessary to use the newly created group.. The first command adds the ejbrole profile for the administrator role for the new authorization group, group2. You can see how the role is built. The first qualifier is the SAF profile prefix for the cell, which ties this role to the S1CELL. The second qualifier is the name of the authorization group which we just created, group2. And the final qualifier is the actual role name, administrator. Please notice that these roles are in mixed case. The case is important and if it doesn t match the actual casing of the prefix, group, and role, it won t work. The second command permits the user, mjloos3, access to the newly created role. This will allow user mjloos3 to have administrator access to the node, s1nodec. The final command is the command which refreshes the in storage copies of the ejbrole profiles, so that the Deployment Manager task which is running the adminconsole application, will have access to them. Ready for more testing

39 Slide 35 So far, still ok. 35 We can still logon to the adminconsole.

40 Slide 36 Let s see what the nodes display looks like 36 As you can see, we can now administer the node, s1nodec, just as we would expect, and still monitor the other nodes.

41 Slide 37 Let s see what happens when we look at servers 37 Since servers are contained within nodes, and we have administrator access to the node s1nodec, you ll see that we now have administrator access to all of the servers contained within the node s1nodec.

42 Slide 38 What about applications? 38 Since applications are actually cell wide resources, we don t get any access via our access to the node. This makes sense.

43 Slide 39 Which resources? 39 Notice that when we are adding the resources to the group, that the servers are selected as part of the node. If you have access to the node, you have access to the servers.

44 Slide 40 Which resources? 40 As you can surmise from looking at the panel, applications are completely separate from nodes and servers and vice versa. Also worth noting, is that you can see from looking at this screen that if you needed access to one of the applications, that it is contained within group1.

45 Slide 41 Summary Fine grained security allows us to allow (or disallow) access to specific artifacts that are part of the WebSphere Application Server configuration. Works for both scripting and the adminconsole. Setup of the authorization mechanism is a two part process. adminconsole to create the resource groups. SAF commands to create the corresponding ejbrole profiles and to allow and deny access to them. 41

46 Slide 42 Questions? 42