Looks like I’ll put off talking about a more pleasing subject of the importance of events for TBSM v4.2 to talk about something I’ve been thinking, playing, struggling with this past week. More details will have to wait until we’re GA here in a few weeks, sorry.
I can’t stress enough that you begin to create a thorough design and implementation plan for how you’ll establish access, authorization and authentication (AAA) within your TBSM v4.2 solution. Things have SIGNIFICANTLY changed in TBSM v4.2. There are many different options and settings throughout the product that must be set to implemented in a typical production environment. Many of them are easy to overlook, trust me!
I recommend starting with a systematic assessment of your existing environment (or strawman of what you think your requirements will be). If my end solution is a TBSM v4.2 layout with numerous views, pages and portlets, navigation and launch in context attributes, you must think through all of these components and document what users, roles or groups can access, see and do things. Are these users authenticated in an external source? What group are they assigned at login? Do they have the correct roles assigned to perform your expected tasks?
From an administrators perspective, you’ll need to think through things in the same manner, ensuring that you can perform the administrative tasks – and have the proper configurations to perform work as if you were a member of the end user group. This is a CRITICAL component, especially when implementing custom canvas dashboard solutions for users/groups.
I have this visual in my head of what this may look like to capture how things may be designed:
At each level, I envision documenting all of the critical configurations and settings with heavy focus on who can access, what can they do/see/click-on, etc. Trust me, there are configuration options at every level that you need to think through. This is especially true if you’re implementing solutions where one user/group can see some things and can’t see others.
Some random thoughts to consider as you work through this stuff:
- Are you using an external source such as LDAP, Active Directory or Netcool/OMNIbus for authentication and authorization? How will you integrate? What will the information exchange be? Do you know what your LDAP/AD group needs from you for configuration?
- Will you take advantage of the new Single Sign On (SSO) capability? How? What products will you want SSO access to from TBSMv4.2 / TIP?
- If you’re using legacy TBSM v3.1, Netcool/RAD or TBSM v4.1.x today, start to really look at what you’re doing and how your end user audiences access and work within this environment.
- What types of users do you have? Read only, have some privileges, superusers, etc.? What PSML, pages, tabs, view points can they see/access?
- What roles do they have today in each respective product? What can they do? What can they see? What menus, options, dialog boxes, check boxes, etc. can they interact with?
- Are you assigning roles to users or roles to groups or both? How should you be assigning roles for effective management? How would you audit this if asked?
- What groups do you have? What roles are assigned to groups?
- What NGF security models have you implemented? Are you controlling access to certain PSMLs, viewpoints, etc?
- Will you allow users to manage events from within TBSM? What permissions will you require from an event management perspective from Netcool/OMNIbus or Netcool/Webtop?
- What Tivoli Common Reporting (TCR) reports or charts will you incorporate into your solution? Will your users be able to design/upload their own?
- If launching out into other products, what AAA is required to allow that user to perform expected tasks, actions, etc. in the remote product (TEPS, ITM, TADDM, TSRM, etc.)
- Do you have additional security requirements such as SSL? Do you use CA Signed Certs or Self Signed Certs? Where do you require communications to be encrypted? (User to GUI, TBSM–>LDAP/AD, TBSM–>Other Product) There’s a GUI for this stuff now so hopefully no more command line and file hacking is required.
- You’ll want to learn as much as possible on this repository concept. (standalone, federated, etc.) More than likely you’ll be digging into WebSphere manuals if you have any significant security requirements. It appears as if you’ll always be in this federated repository mode using a local file and other source.
Shameless plug
IBM Tivoli Services and our TBSM AAA Accredited Business Partners are always available to help advise and consult with you in these areas. Please do not hesitate to contact me at anytime and I can help arrange further discussions.
Comments on this entry are closed.