TPM 7.1.1 and TPM 5.1.1 Security Technologies Lewis Lo – TPM 7.1.1 and TPM 5.1.1 Security Technologies 23 Feb 2011 TPM 7.1.1 and TPM 5.1.1 Security Technologies

TPM 5.1.1.x Security Technologies TPM 5.1.1.x runs on WAS 6.0.x TPM 5.1.1.x adopts the default to denied access security policy. That, user does not have access to resources initially even where there is no restriction defined It offers an OS authentication service so that user for the application can be an OS user (Unix and Windows users) TPM 5.1.1.x uses the Access Group for grouping the resources to be protected LDAP is for role based security for UI security, access to menus and buttons in the UI page Two modes are supported in TPM 5.1.1.x which use LDAP Users and roles are in LDAP, authentication and authorization services obtain information from LDAP directly Only users are in LDAP, authenticating user consults LDAP. Roles information is obtained in TPM database. Support role base security for UI, access control, and workflow security Web service interface entitles to access control and workflow security Permissions for access control are part of the permissions in workflow security Source: If applicable, describe source origin

TPM 7.1.1 Security Technologies TPM 7.1.1.x runs on Maximo which runs on WAS 6.1.0.29 TPM 7.1.1.x is no longer a Web Application on its own It adopts the default to granted access security policy, that is, user has access to all resources if there is no restriction defined It offers a maximo authentication service, it is a proprietary authentication service which have users and user passwords stored in the database. Authentication is performed on Maximo security service, no interface to WAS security required It uses TPM provisioning group for security purpose Static group – members in static groups are managed explicitly Dynamic group – a query is defined for every dynamic group, and membership is determined at run time by running the query (similar to sql query) It supports two modes security services with LDAP Users and roles are in LDAP, authentication and authorization services obtain information from LDAP directly Only users are in LDAP, authenticating user consults LDAP. Roles information is obtained in Maximo database.

TPM 7.1.1 Security Technologies - Continued TPM 7.1.1 uses the notion of Security Group which is identified in LDAP Security Group is for UI, access control, and workflow security Web service interface entitles to access control and workflow security Permissions for access control and workflow security are decoupled Access control security uses Maximo security framework Workflow security uses TPM internal security framework FIPS enabled PKCS 12 formatted keystore and truststore are supported TLS is supported

Major differences in TPM 5.1.1 and TPM 7.1.1 Default to denied access Default to granted all access Access Group (static) for protected resources Provisioning groups (static or dynamic) for protected resources. Provisioning groups can be typed LDAP groups are for UI security only. Security for access control and workflow are managed separately LDAP groups are used for all security measures; including UI, access control, and workflow. Users in the same group will obtain the set of permissions granted to the same set of resources Support OS authentication service No OS authentication service No proprietary authentication service supported Support Maximo proprietary authentication service Non-FIPS FIPS supported with TLS protocol

TPM 7.1.1 security overview TPM 7.1.1 security consists of the following components Maximo Security Service : the engine to perform security related tasks, including authentication and authorization of users Data restriction component : defines the data restrictions for accessing the instances of object, read or write access Security Group : Contains the security information for the Maximo Security Service. Information includes user, permission, and resources to be protected. Provisioning Group : A TPM specific group to contain TPM objects, can be used for security purpose.

Role Base Security Maximo Security Service WebSphere Security Service 6 Maximo Security Service 1 7 2 5 WebSphere Security Service Users and Roles info LDAP 3 4

Control Flow of Authentication and Authorization User attempts to access TPM, and a challenge page is presented. User input username and password. Control passes to the Maximo Security Service Maximo Security Service delegates the authentication service to WebSphere WebSphere contacts the LDAP to retrieve user information, including the roles the user is a member of WebSphere performs a LDAP binding operation for the user, LDAP returns a response if the user provides a valid username and password Suppose the user enters a valid username and password, WebSphere returns a successful logon message to Maximo Security Service. Maximo Security Service consults the access control list for the TPM UI, the access control list contains information on what UI the role of the user have access to Maximo Security Service renders the UI pages based on the roles the user has and the access control lists of the UI for the roles

Instance Access Security There are two types of instance permissions Read/Write permission: governs the readonly and write access to an object. User can only write to an object if and only if he has write access to the instance of object. Workflow Security: a workflow is protected when permission is required to run Permissions required for a workflow is declared in the workflow definition User is assigned to a security group A permission group contains permissions A provisioning group contains TPM objects to be protected Example of protected workflow @requirepermission Software.Install clusterId @requirepermission Software.Start clusterId logicaloperation test.test (clusterId) LocaleInsensitive invokeimplementation

Example of running a Device Reboot workflow Provisioning Group (PG1) server1 Security Group (SG1) User 1 Device.Reboot permission User 2 Provisioning Group (PG2) server2 Security Group (SG2) Device reboot Workflow Device.Reboot permission

Example of running a Device Reboot workflow Security Group (SG1) has user members of user1 and user2 Security Group (SG2) has user member of user2 Provisioning group (PG1) contains sever1 which ties to Security Group (SG1) Provisioning group (PG2) contains server2 which ties to Security Group (SG2) Both security groups (SG1 and SG2) consists of the permission Device.Reboot User1 is granted permission Device.Reboot on server server1 User2 is granted permission Device.Reboot on servers server1 and server2, since user2 is a member of both security groups SG1 and SG2 When running a workflow that requires the permission Device.Reboot, User1 can only execute the workflow on target server1 User2 can execute the workflow on both targets, i.e. sever1 and server2

Role Mapping TPM 5.1.1.x to TPM 7.1.1 <?xml version="1.0"?> <Mapping> <Roles> <Role name="SystemAdministrator"> <ITUPRole>TPADMIN</ITUPRole> </Role> <Role name="InventorySpecialist"> <ITUPRole>TPCONFIGURATIONLIBRARIAN</ITUPRole> <Role name="SoftwareOperator"> <ITUPRole>TPCOMPLIANCEANALYST</ITUPRole> <ITUPRole>TPDEPLOYMENTSPECIALIST</ITUPRole> <Role name="ChangeApprover"> <Role name="AutomationPackageDeveloper"> <ITUPRole>TPDEVELOPER</ITUPRole> <Role name="ConfigurationAdministrator"> <Role name="ConfigurationOperator"> </Roles> </Mapping>

Resource Links to security groups and application access rights http://publib.boulder.ibm.com/infocenter/tivihelp/v28r1/topic/com.ibm.tivoli.tpm.scenario.doc/security/rsec_secgroupapp.html http://publib.boulder.ibm.com/infocenter/tivihelp/v28r1/topic/com.ibm.tivoli.tpm.scenario.doc/security/csec_predefinedgroups.html

For more security information, please visit our: TPM DeveloperWorks Wiki – Security and Audit http://www.ibm.com/developerworks/wikis/display/tivoliprovisioningmanager/Security+and+Audit TPM 7.2.0.1 Information Center – Security http://publib.boulder.ibm.com/infocenter/tivihelp/v45r1/topic/com.ibm.tivoli.tpm.scenario.doc/security/csec_security.html