Security services

Application server security

At the application server level, InfoSphere MDM enterprise beans and web services port components are configured for each method to only grant access to users in particular roles. InfoSphere MDM relies on the application server to perform user authentication. The identities being authenticated are those of the systems consuming the functionality of InfoSphere MDM.

InfoSphere MDM defines two security roles: ServiceConsumer; and ServiceProvider. All user identities that are authenticated by the application server are placed in the ServiceConsumer role.

The methods of the enterprise beans that constitute entry points for other applications (the ServiceController bean, the ProcessControlInternal bean and the web services beans) are configured to grant access to the ServiceConsumer role. Also, these beans use the ServiceProvider role as RunAs security role.

All of the other enterprise beans, which are not meant to be accessed directly by other applications, have their methods configured.

The ServiceProvider RunAs security role must be bound at deployment time to an actual user identity in the user registry used by the application server. By default, InfoSphere MDM binds this role to the InfoSphere MDM user identity.

You can either create an InfoSphere MDM identity in you user registry or bind the role to a different user identity. This identity should not be used for any other purposes and should be reserved for the use of InfoSphere MDM enterprise application.

Application security

In non-TrustedClientMode, the InfoSphere MDM operational server uses the username and role details of the authenticated user to process an MDM service request.

The security service provides a framework for externalizing access policy decisions. The framework defines the interfaces that a transaction authorization provider must implement to provide the InfoSphere MDM application with access policy decisions on business transactions. InfoSphere MDM comes with a default transaction authorization provider which uses a relational database to store information about security policy. In addition to that, a transaction authorization is provided that uses an LDAP directory to store security access policy information.

The security service also provides a framework for formatting of the authentication assertions. The framework defines the interface required to parse authentication assertion included in the transaction requests. InfoSphere MDM comes with a default authentication assertion parser that supports the use of SAML (Security Assertion Markup Language).

For information about LDAP usage, see Managing users.

Understanding TrustedClientMode

If InfoSphere MDM is deployed without application security, TrustedClientMode will be true. This means that the service will be processed using the user name that is mentioned in the requesterName property of the DWLControl.

If deployed with application security enabled, then the following configurations decide whether TrustedClientMode is enabled.

/IBM/DWLCommonServices/Security/TrustedClientMode/enabled

• This configuration is false by default, which means that the InfoSphere MDM operational server will process the requested transaction using the identity of the user who calls the service (for example, the user who is authenticated by the container).
• When this is true, the InfoSphere MDM operational server will process the requested service using the identity that is specified in the requesterName property of the DWLControl. (Prior to InfoSphere MDM version 11.0, the user name mentioned in the requesterName property of the DWLControl is always used. This configuration will be used to enforce backward compatibility.

TrustedClientMode for channels

If the InfoSphere MDM service requests are sent from an external channel other than RMI and WebServices, then TrustedClientMode will be true by default. This means the requested process will be serviced by using the identity that is specified int he requesterName property of the DWLControl. (This is because the channel requests are mostly accumulated from different sources and executed by an authorized user in one shot. Therefore individual requests may be owned by the user whose name is mentioned in the requesterName property of the DWLControl of each request.)

For security purposes, the server validates the userRole of the executing user whether the role is configured in the Channel/roles configurations.