Chapter 9. Service Provider Setup

Once an IdP has been defined as the identity source that will be used to back authentication processes, the next step is to define the trusted partner sites that will consume the claims made by the IdP on behalf of any given user.

Service Providers will build on this claim set to authorize service requests made by end users and applications.

From the Palette, click "Service Provider" in the "Entities" drawer.

Drag the "Service Provider" element to the preferred location within the Diagram Canvas.

In the "New Service Provider Definition" window, enter the name of the Service Provider (SP).

On the "Core" screen, specify how consumers will reach the endpoints of the SP. The default location is built using attributes supplied at identity appliance-creation time. For the sake of consistency, we strongly suggest leaving the attributes as-is.

Field Descriptions

Field	Description
Name	The unique identifier of the SP.
Description	A descriptive text for the SP.
Location	The access protocol - whether http or https - host name, port and context path where the endpoints for the SP will be bound. Clients will refer to services provided by the SP using URIs which are qualified using this location value. We strongly suggest that you use a fully qualified host name, so that the identity appliance services are decoupled from a specific physical host.
Account Linkage Policy	The means by which input claims, conveyed in the security token, which are issued and submitted by a trusted IdP, will be mapped to output claims; which will in turn be consumed by the relevant party in order to authorize users and grant them appropriate access. Select "Use Theirs" to link IdP and SP accounts using the supplied name identifier, and to map input to output claims in a one-to-one fashion. Select "Use Ours" to link IdP and SP accounts using the supplied name identifier, and to issue output claims based only on the user details that are available within the identity source connected with the SP. Select "Aggregate" to link IdP and SP accounts using the supplied name identifier, and to issue output claims based on merging both the user details conveyed in the security token and those obtained from the identity source connected to the SP.

On the Contract screen, specify the IdP-facing SAML Profiles and Bindings to enable.

You can also check on the level of security of the artifacts involved in message exchanges between SPs and the IdP.

Field Descriptions

Field

Description

Enabled SAML Profiles

The SAML Profile to activate for this IdP.

These mainly represent the usage scenarios realized by the SP.

The most important SAML profile is the "Web Browser Single Sign-On Profile", which can be enabled by selecting the SSO checkbox.

Select the SLO checkbox to enable Single Logout Support.

Enabled SAML Bindings

The SAML bindings to be enabled for the selected SAML profiles.

These specify the mapping of a SAML protocol message onto standard messaging formats and/or communications protocols.

Select the Http Post checkbox to convey SAML messages through HTTP Post.

Select the Http Redirect checkbox to convey SAML messages through HTTP Get.

Select the Artifact checkbox to convey SAML messages through the SAML Artifact Binding, which builds on both HTTP Redirect and SOAP bindings to exchange SAML messages.

Select the SOAP checkbox to convey SAML messages through SOAP over HTTP(s).

On the Certificate screen, select the keystores which hold the private and public key pairs to secure SAML message exchanges between SPs and the IdP.

This involves setting up the building blocks of the trust system, which is based on public key infrastructure (PKI). The trust system provides peer authentication, integrity, confidentiality and non-repudiation in a transport-agnostic fashion. The SAML standard - which JOSSO supports - builds on PKI to guarantee these security attributes for SSO message exchanges. The requested information is mainly used for providers to access private and public key pairs.

Field	Description
Use Default Keystore	Use the built-in keystore portion of the distribution. We recommend this for sandbox settings only, where security is not really an issue. Within a production system, using a custom keystore is strongly recommended.
Upload the keystore file	Select this option if you wish to use a custom keystore.
Certificate/Key Pair	Allows you to select the desired keystore file from the local filesystem.
Format	The Keystore Format for the uploaded keystore file. Choose "Java Keystore" which is currently the only supported keystore format. It is expected that the PKCS#12 will be supported in future releases.
Keystore Password	Password that providers will use to open the keystore, to obtain the private and public certificate pairs that are required to secure SSO exchanges.
Certificate Alias	Identifier of the keystore entry for the public key. The public key is used, for instance, to validate the digital signature conveyed in SAML messages, to identify the requester and the integrity of the messages.
Key Alias	Name of the keystore entry used to obtain the corresponding private key. The private key is used, for instance, to digitally sign SAML messages.
Key Password	The password required to obtain the private key.

Field	Description
Name	The unique identifier for the execution environment.
Description	A descriptive text for the execution environment.
Target Host	The host where the Alfresco CMS instance is located. The available options are "Local" and "Remote". If the "Local" option is selected, it is assumed that the execution environment will be found within the same host that is running JOSSO2. Alternatively, if the "Remote" option is selected, it is assumed that the execution environment will be located within a different host than the one that's running JOSSO2.
Install Home	The folder hosting the artifacts of the Alfresco CMS server instance.
Remote JOSSO 2 URL	The endpoint of the activation web service for the remote JOSSO2 instance. In order for the remote activation to be successful, the target execution environments need to be located within the same host as the remote JOSSO2 instance. This field is only shown if the remote target host option is selected.
Container Type	The web container flavour on top of which the Alfresco CMS server is deployed.
Container Home	The folder hosting the web container on top of which the Alfresco CMS server runs.
Overwrite Original Setup	Select this option if the execution environment has been previously activated, either from the JOSSO1 command line console or through the Atricore Console, and you wish to replace the original settings with new ones.

Field	Description
Name	The unique identifier for the execution environment.
Description	A descriptive text for the execution environment.
Target Host	The host where the Apache Web Server instance is located. The available options are "Local" and "Remote". If the "Local" option is selected, it is assumed that the execution environment will be found within the same host that is running JOSSO2. Alternatively, if the "Remote" option is selected, it is assumed that the execution environment will be located within a different host than the one that's running JOSSO2.
Install Home	The folder hosting the artifacts of the Apache Web Server instance.
Remote JOSSO 2 URL	The endpoint of the activation web service for the remote JOSSO2 instance. In order for the remote activation to be successful, the target execution environments need to be located within the same host as the remote JOSSO2 instance. This field is only shown if the remote target host option is selected.

Field	Description
Name	The unique identifier for the execution environment.
Description	A descriptive text for the execution environment.
Target Host	The host where the JavaEE server instance is located. The available options are "Local" and "Remote". If the "Local" option is selected, it is assumed that the execution environment will be found within the same host that is running JOSSO2. Alternatively, if the "Remote" option is selected, it is assumed that the execution environment will be located within a different host than the one that's running JOSSO2.
Install Home	The folder hosting the artifacts of the JavaEE server instance.
Remote JOSSO2 URL	The endpoint of the activation web service for the remote JOSSO2 instance. In order for the remote activation to be successful, the target execution environments need to be located within the same host as the remote JOSSO2 instance. This field is only shown if the remote target host option is selected.

Field	Description
Name	The unique identifier for the execution environment.
Description	A descriptive text for the execution environment.
Target Host	The host where the JBoss Portal instance is located. The available options are "Local" and "Remote". If the "Local" option is selected, it is assumed that the execution environment will be found within the same host that is running JOSSO2. Alternatively, if the "Remote" option is selected, it is assumed that the execution environment will be located within a different host than the one that's running JOSSO2.
Install Home	The folder hosting the artifacts of the JBoss Portal server instance.
Remote JOSSO 2 URL	The endpoint of the activation web service for the remote JOSSO2 instance. In order for the remote activation to be successful, the target execution environments need to be located within the same host as the remote JOSSO2 instance. This field is only shown if the remote target host option is selected.
Overwrite Original Setup	Check in cases where the execution environment has been previously activated, either from the JOSSO1 command line console or through the Atricore Console, and you wish to have the original settings replaced with new ones.
Install Demo Applications	Check, if deploying JOSSO example web applications onto the target execution environment. We strongly recommend that you check this field in order to verify that the Internet SSO setting works as expected, before engaging in SSO-enabling candidate business applications.