Security on JMS Service  

Security Aspects

The J2EE Engine JMS Provider implements the following security aspects:

·        Authentication

The TopicConnectionFactory is always obtained via JNDI. This is why the J2EE Engine forces authentication for JNDI clients. Only the clients that are authenticated against the JNDI login context can obtain a connection factory and create a JMS Connection. This user authentication is performed in one of the first steps you must follow to create a JMS Connection. The JMS API provides the following two variants to make the authentication. You can:

Ў        Provide a user name and password:

The Security Provider Service of the session container forces authentication against the configured policy configuration for JMS basic password authentication.

Ў        Choose not to provide any credentials:

You must initialize the connection using SSL. The Security Provider Service of the session container then forces authentication against the policy configuration that is configured for JMS X.509 certificate authentication. Otherwise, the anonymous user is configured for J2EE Engine.

·        Authorization

J2EE Engine authorization of the JMS Connection enables you to apply restrictions over:

Ў        JMS Clients actions. You can prevent the client from:

§         Creating a Producer to a destination.

§         Creating a Consumer to a destination.

§         Creating a Browser to a destination.

§         Connecting to a durable subscription on a destination.

§         Creating a durable subscription on a destination.

§         Creating destination with createQueue/createTopic.

§         Creating a temporary destination.

Ў        JMS administrator actions

All administration tasks are checked against a predefined security role JMSAdministrators in the policy configuration of the Security Provider Service.

Authorization and authenticaiton

Objects created for JMS using the Visual Administrator are stored in the JNDI. Such objects can contain user information such as passwords and if a user gains access to JNDI, then he or she can access the JMS configuration and other objects that have been created. We recommend that, in addition to protecting access (read, write, create) to the JMS service, you should restrict the access to the JNDI service using security roles.

jms.authorization defines the following resources:

Resource	Actions	Description
queue	·        consume ·        produce ·        browse	The resource for all queues. It has instances for each queue in the JMS Provider
topic	·        consume ·        produce ·        create-durable-subscription ·        connect-durable-subscription	The resource for all topics. It has instances for each topic in the provider. For hierarchical topics the instances are grouped
subscription	·        change-topic ·        change-selector ·        close	The resource for all durable subscriptions
connection	·        create-destination ·        create-temporary-destination	The resource for client tasks that do not have to deal with a specific destination
administration	·        create-topic ·        create-queue ·        create-subscription ·        remove-topic ·        remove-queue ·        remove-subscription – if an instance is used, it specifies the target of the task	The resource for administrative tasks

Policy configurations

The policy configurations for the JMS provider are created using the Security Provider Service interfaces. The following configurations are created:

Configuration	Description
jms.<jms-instance-name>. authentication.basic	Contains the authentication configuration for login using username-password. When it is created, it is set up from the policy configuration basic.
jms.<jms-instance-name>. authentication.cert	Contains the authentication configuration for login using X.509 certificate. When it is created, it is set up from the policy configuration client-cert.
jms.<jms-instance-name>. authorization	Contains restrictions for administrative tasks such as creating a destination as well as default client action restrictions. The JMS Provider has two security roles named JMSAdministrators, which reference the preconfigured security role administrators of the policy configuration SAP-J2EE-Engine, and JMSClients, which references the preconfigured security role guests of policy configuration SAP-J2EE-Engine. JMSAdministrators is granted to all administrative rights and JMSClients to all client actions. Additional security roles can be defined by an administrator.

These policy configurations are configured by the J2EE Engine Security Service and are changed according to changes in the active user store.

For more information about managing the user stores on the server, see Managing User Stores in the Administration Manual.

Restrictions for message selectors

You can apply restrictions for the message selectors as follows:

For the instance of a destination, a number of message selection boundaries can be defined as grouped instances. When a consumer with a selector is created, the Security Service will go through all these boundaries to check if the consumer and selector combination passes all of them.

For a queue named stocks with two boundaries: a group of users authorized are allowed to view the messages on all stocks and another group called not_authorized is limited to stocks with IDs greater than 1000.

Define two security roles then:

·        authorized with the authorized users.

·        not_authorized with the others users.

 We define the following instances of resource queue:

·        queue
     stocks
     “stock-id <= 1000” – authorized
      “”                - authorized, not_authorized

Communication Protocols and Ports

The JMS provider differentiates between internal and external communication.

·        JMS internal communication is communication that takes place within the J2EE Engine cluster. Therefore, for internal communication both JMS and the application operate in the same runtime and therefore no extra security is necessary.

·        External communication takes place using an SAP-proprietary binary format. The port used is obtained from the dispatcher. The default port is 5<sid>10, however, you can change this port in the server port definitions. The protocol used for JMS can only be transferred using this port. When communicating over network boundaries, this port must be opened on the firewall.

No encryption is available on the JMS communication. Even though the binary format is hard to decode this may imply a security risk if messages contain sensitive information.

Data Storage

Configuration data and user data (messages) are stored in the database and underlie the database protection mechanisms.