Security configurations for SCA applications

Security for SCA components and bindings can be configured using intents, SCA policy sets, web services policy sets, and WAS security configuration.

The following sections describe how security can be configured for each of the different bindings and implementation types that SCA supports in a WAS environment. Refer to the topic Use SCA authorization and security identity policies for more information about authorization and security identity policies. Refer to the topic Security: Resources for learning for more general information about WAS security features.

Security configurations for SCA bindings

The following list summarizes the security that can be configured for the bindings supported for SCA applications.

binding.sca

No security-related intents or policy set attachments are supported. Your server configuration and CSIv2 settings control authentication and encryption. Refer to the topics Set up, enabling and migrating security, and Configure CSIv2 (CSIV2) inbound and outbound communication settings for more information.

binding.ejb

No security-related intents or policy set attachments are supported. Your server configuration and CSIv2 settings control authentication and encryption. Refer to the topics Set up, enabling and migrating security, and Configure CSIv2 (CSIV2) inbound and outbound communication settings for more information.

binding.ws

A service binding can be configured to require transport layer authentication using the authentication.transport intent for OSOA composites or the clientAuthentication.transport intent for OASIS composites. A service binding can be configured to require transport layer encryption using the confidentiality.transport intent. All other security is configured by attaching web services policy sets. Refer to the topics Mapping abstract intents and managing policy sets and Secure web services using policy sets for more information.

binding.jms

An authentication alias can be specified on the reference binding or service binding in the composite file to authenticate with a secure bus. binding.jms does not propagate the identity of the client. Refer to the topic Secure buses for more information.

binding.atom (OSOA composites only)

On the service side, authentication.transport and confidentiality.transport intents in the composite file are used to configure transport layer authentication and encryption. On the reference side, an authentication alias can be configured to send a username and password with the request. If a LTPA token already exists in the security context, the LTPA token is propagated with the request. Refer to the topics Securing data exposed by Atom bindings, and Configure LTPA and working with keys for more information.

binding.http (OSOA composites only)

On the service side, authentication.transport and confidentiality.transport intents in the composite file are used to configure transport layer authentication and encryption. On the reference side, if a LTPA token already exists in the security context the LTPA token is propagated with the request. Refer to the topics Secure services exposed by HTTP bindings, and Configure LTPA and working with keys for more information.

Security configuration for SCA implementation types

The following list summarizes the security that can be configured for the implementation types supported for SCA applications.

implementation.java

Authorization and security identity policies are specified by attaching an SCA policy set in the composite file or by using annotations in the composite implementation. Refer to the topic Use SCA authorization and security identity policies for more information.

implementation.spring (OSOA composites only)

Authorization and security identity policies are specified by attaching an SCA policy set in the composite file or by using annotations in the composite implementation. Refer to the topic Use SCA authorization and security identity policies for more information.

implementation.osgiapp (OSOA composites only)

We can attach an SCA policy set containing authorization policy statements to an implementation.osgiapp component. The policy set applies to all services of the component that are started through SCA service bindings, but not internally when the OSGi application uses its own services.

SCA does not support the use of the org.osoa.sca.annotations.PolicySet annotation or the annotations in the javax.annotation.security package in Blueprint implementation classes. The configuration of role-based security for SCA components is independent of the configuration of role-based security for a web application bundle (WAB). The roles and role mappings used for SCA components and for WABs are separate.

implementation.osgiapp (OSOA composites only)

Authorization and security identity policies are specified by the deployment descriptors in the JEE application. See the topic Securing enterprise bean applications for more information.

implementation.ejb (OSOA composites only)

Authorization and security identity policies are specified by the deployment descriptors in the JEE application. See the topic Securing enterprise bean applications for more information.

implementation.jee (OSOA composites only)

Authorization and security identity policies are specified by the deployment descriptors in the JEE application.

implementation.web (OSOA composites only)

HTTP authorization and security identity policy are not supported for implementation.web. We must use JEE security constraints in the web.xml. file to configure authorization for the resources in the WAR package.

Related tasks

Set up, enabling and migrating security

Configure CSIv2 (CSIV2) inbound and outbound communication settings

Mapping SCA abstract intents and managing policy sets

Secure web services using policy sets

Secure buses

Secure data exposed by Atom bindings

Configure LTPA and working with keys

Secure services exposed by HTTP bindings

Use SCA authorization and security identity policies

Secure enterprise bean applications

Security: Resources for learning