Administration Console Online Help

Servers: Configuration: Federation Services: SAML 2.0
General

If you are configuring SAML 2.0 services for web single sign-on, note
the following:

Click Publish Meta Data only after you have configured the
SAML 2.0 Identity Provider or Service Provider services.

If this SAML Authority site is configured to serve in the role of
Identity Provider with some partners, and Service Provider with other
partners, you should maintain a single version of this metadata file.
This helps prevent messages from being rejected due to incompatible
single sign-on settings.

If you are configuring SAML 2.0 services on two or more server
instances in a domain, you must configure the RDBMS security store.

Specifies whether the persistent cache (LDAP or RDBMS) is used
for storing SAML 2.0 artifacts and authentication requests.

RDBMS is required by the SAML 2.0 security providers in
production environments. Use LDAP only in development
environments.

If this is not set, artifacts and requests are saved in
memory.

If you are configuring SAML 2.0 services for two or more
WebLogic Server instances in a domain, you must enable the
replicated cache individually on each server. In addition, if you
are configuring SAML 2.0 services in a cluster, each Managed Server
must also be configured individually.

When publishing SAML 2.0 metadata, this URL is used as a base
URL to construct endpoint URLs for the various SAML 2.0 services.
The published site URL is also used during request processing to
generate and/or parse various URLs.

The hostname and port portion of the URL should be the hostname
and port at which the server is visible externally; this may not be
the same as the hostname and port by which the server is known
locally. If you are configuring SAML 2.0 services in a cluster, the
hostname and port may correspond to the load balancer or proxy
server that distributes client requests to servers in the
cluster.

The remainder of the URL should be a single path component
corresponding to the application context at which the SAML 2.0
services application is deployed (typically
/saml2).

If enabled, callers to TLS/SSL bindings of the local site must
specify client authentication (two-way SSL), and the identity
specified must validate against the TLS certificate of the binding
client partner.

The passphrase used to retrieve the server's private key from
the keystore.

If you do not specify either an alias or a passphrase, the
server's configured SSL private key alias and private key
passphrase from the server's SSL configuration is used for the TLS
alias and passphrase by default.

If enabled, callers to HTTPS bindings of the local site must
specify a Basic authentication header, and the username and
password must be validated against the Basic authentication values
of the binding client partner.

The maximum timeout (in seconds) of artifacts stored in the
local cache.

This cache stores artifacts issued by the local site that are
awaiting referencing by a partner. Artifacts that reach this
maximum timeout duration are expired in the local cache even if no
reference request has been received from the partner. If a
reference request is subsequently received from the partner, the
cache behaves as if the artifact had never been generated.

The key is used to generate signatures on all the outgoing
documents, such as authentication requests and responses. If you do
not specify an alias, the server's configured SSL private key alias
from the server's SSL configuration is used by default.