[AIX Solaris HP-UX Linux Windows][z/OS]

Security configurations for SCA applications

Security for SCA components and bindings can be configured using intents, SCA policy sets, web services policy sets, and WebSphere® Application Server 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 WebSphere Application Server environment. Refer to the topic Using 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 WebSphere Application Server 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 Setting up, enabling and migrating security, and Configuring Common Secure Interoperability Version 2 (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 Setting up, enabling and migrating security, and Configuring Common Secure Interoperability Version 2 (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 Securing 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 Securing 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 Configuring 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 Securing services exposed by HTTP bindings, and Configuring 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 Using 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 Using SCA authorization and security identity policies for more information.
implementation.osgiapp (OSOA composites only)
You 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. You must use JEE security constraints in the web.xml. file to configure authorization for the resources in the WAR package.
Concept topic    

Terms and conditions for information centers | Feedback

Last updated: April 20, 2014 08:46 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-mp&topic=csca_security
File name: csca_security.html