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.