Database Reference
In-Depth Information
Configuring
OWSM
policies
for
Oracle SOA components
Since the 11g release, OWSM has been integrated with SOA Suite. This means
you now have a greater ease of managing web service policies for security and
administration of your SOA components. OWSM defines security through extern-
ally defined policies that are applied to the web service components at invoca-
tion time rather than applying security during implementation. At the server side,
a security policy attached to the consumer adds the required security token to
the SOAP header and performs assertions specified in the policy. At the provider
side, an equivalent policy pair validates all the security tokens and delegates the
assertion to the Oracle Platform Security Services (OPSS) layer, discussed
shortly, which then verifies its validity against the configured identity store. Most of
the security related configuration and administration can be done through Oracle
Enterprise Manager Fusion Middleware Control.
A set of predefined security policies are persisted in the MDS, enabling them to
be available at both design time and runtime. Policies in OWSM are defined gen-
erically without any context, that is, in general they are not application specific.
There are a number of ways in which you can attach or detach OWSM policies to
composite artifacts, which is discussed in detail later, but before that you should
know that most policies require additional configuration on the infrastructure first.
Consider a few examples:
Policy endpoints that are password protected need to have an OPSS creden-
tial store setup.
Policies requiring message protection through encryption require keystore
setup with a self-signed certificate or one issued by a certificate authority
(CA) .
Authentication and authorization policies require an identity store to be set up,
which can either be LDAP, OID, OAM, and so on.
WS-Trust-based policies require Secure Token Service (STS).
Search WWH ::




Custom Search