JOSSO.orgCommunity Documentation

Chapter 9. Service Provider Setup

9.1. Set Up the Identity Source of the Service Provider
9.1.1. Using an Identity Vault as the Authoritative Source for the Service Provider
9.1.2. Using an LDAP Directory as the Authoritative Source for the Service Provider
9.1.3. Using an RDBMS as the Authoritative Source for the Service Provider
9.1.4. Using XML files as the Authoritative Source for the Service Provider
9.2. Set Up the Execution Environment of the Service Provider
9.2.1. Using an Alfresco Execution Environment
9.2.2. Using an Apache Web Server Execution Environment
9.2.3. Using a JavaEE Execution Environment
9.2.4. Using a JBoss Portal Execution Environment
9.2.5. Using a Liferay Portal Execution Environment
9.2.6. Using a phpBB Execution Environment
9.2.7. Using a Webserver Execution Environment
9.2.8. Using an Oracle Weblogic Execution Environment
9.2.9. Using a Websphere Community Edition (WASCE) Execution Environment
9.2.10. Using a Windows IIS Execution Environment
9.2.11. Using an Apache Tomcat Execution Environment
9.2.12. Using a JBoss Execution Environment

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 Descriptions

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.

Click on OK to confirm SP element creation.

Click on Cancel to abort SP element creation.

An SP may build on an identity source in order to link the IdP account with a local counterpart, and employ the user details available in the IdP account to augment output claims.

Associating an SP with an Identity Source is not mandatory. Only use this feature when augmenting claims pushed by trusted IdPs with information available in an SP-local store.

To define a local identity source for an SP, drag one of the available identity sources and connect it to the target SP, using the "identity lookup" edge.

One or more SPs can be hosted applications or resources within an Apache Web Server instance.

Alfresco offers true Open Source Enterprise Content Management (ECM): Document Management, Collaboration, Records Management, Knowledge Management, Web Content Management and Imaging.

In order to build the SP on an Alfresco execution environment, you must define the Alfresco execution environment element, and associate it with the SP.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the Alfresco CMS execution environment details :

Field Descriptions

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.

In order to use an XML source as the identity store for an IdP, an Identity Lookup connection must be established between them both.

From the Palette, click "Identity Lookup" in the "Connections" drawer.

Click on the source SP element, and drag the edge to the target XML Identity Source element.

An edge should appear, connecting the SP and XML identity source elements.

The Apache HTTP Server is a popular open source, standard, secure, efficient and extensible HTTP server for modern operating systems, including UNIX and Windows NT.

An Apache HTTP Server can run virtually all types of web applications, such as those written in PHP, Perl, Ruby and Python among many others.

Establishing an activation connection between an SP and an Apache Web Server Execution Environment implies that the SP is a web application, hosted by an Apache Web Server instance.

There is no support for automatic activation upon an Apache Web Server execution environment that is connected with an SP.

Applications running under Apache Web Server can be SSO-enabled seamlessly, without having to couple the application to the underlying SSO infrastructure, and deal with SSO internals.

Once a successful security context is established, the web application - playing the service provider role - can consume it by relying on the REMOTE_USER environment variable set as the JOSSO Agent for Apache Web Server.

This variable contains the user name of the authenticated user. The REMOTE_USER value can be used to search for the user details as well as any other business-specific user profile information.

From the Palette, click in the "Execution Environments" drawer.

Within the setup dialog, enter the Apache Web Server execution environment details :

Field Descriptions

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.

Java Platform, Enterprise Edition or Java EE is a widely used platform for server programming in the Java programming language. The Java platform (Enterprise Edition) differs from the Java Standard Edition Platform (Java SE) in that it adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server.

In order to build the SP on a JavaEE execution environment, define a JavaEE Execution Environment element and associate it with the SP.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the JavaEE execution environment details :

Field Descriptions

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.

JBoss Portal provides an open source and standards-based environment for hosting and serving a portal's Web interface, publishing and managing its content, and customizing its experience. It is entirely standards-based and supports the JSR-168 portlet specification, which allows you to easily plug in standards-compliant portlets to meet your specific portal needs.

In order to build the SP on the JBoss Portal execution environment, define a JBoss Portal Execution Environment element and associate it with the SP.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the JBoss Portal execution environment details :

Field Descriptions

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.

Liferay Portal is an enterprise open source portal framework, offering integrated Web publishing and content management, an enterprise service bus and service-oriented architecture, and compatibility with all major IT infrastructure.

In order to build the SP on a Liferay Portal execution environment, you must define the Liferay Portal execution environment element, and associate it with the SP.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog enter the Liferay Portal execution environment details :

Field Descriptions

Field

Description

Name

The unique identifier for the execution environment.

Description

A descriptive text for the execution environment.

Target Host

The host where the Liferay 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 Liferay 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.

Container Type

The web container flavour on top of which the Liferay Portal server is deployed.

Container Path

The folder hosting the web container on top of which the Liferay Portal server runs.

Overwrite Original Setup

Check, if 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, to deploy 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.

phpBB is a free flat-forum bulletin board software solution that can be used to stay in touch with a group of people, or can power your entire website.

In order to build the SP on a phpBB Portal execution environment, you must define the phpBB execution environment element, and associate it with the SP.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog enter the phpBB execution environment details :

Field Descriptions

Field

Description

Name

The unique identifier for the execution environment.

Description

A descriptive text for the execution environment.

Target Host

The host where the PhpBB 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 phpBB forum application.

Remote JOSSO2 URL

The endpoint of the activation web service for a 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, if 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, to deploy 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.

A web server execution environment represents a generic web server (or container) hosting web applications or resources. Activation is not supported for this environment.

In order to build the SP on a Web server execution environment, you must define the Web Server execution environment element, and associate it with the SP.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the Web Server execution environment details :

Field Descriptions

Field

Description

Name

The unique identifier for the execution environment.

Description

A descriptive text for the execution environment.

Target Host

The host where the 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 JavaEE container.

Remote JOSSO 2 URL

The endpoint of the activation web service for a 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.

WebLogic Server is a J2EE-compliant application server, produced by Oracle. It implements the full range of J2EE technologies, and provides features such as advanced management, clustering, and web services. It forms the core of the WebLogic platform, and provides a framework for building scalable, highly available and secure applications.

JOSSO supports SSO-enabling JavaEE applications running under Oracle WebLogic Server 9 and 10. Both web and business layers can be SSO-enabled. For instance, within a 3 or n-tier setting, once the security context is established on the web tier, JOSSO will seamlessly propagate it to the potentially distributed business tier. A business tier realized using Enterprise Java Beans (EJB) - namely Session Beans - will then be able to leverage the security context by applying the EJB-specific access control rules in both declarative - through Java annotations - and programmatic form.

Establishing an activation connection between a SP and a WebLogic Execution Environment implies that the SP is a standard JavaEE application hosted by a WebLogic Server instance.

Launching the activation on a WebLogic Server execution environment triggers the provisioning of the specific SSO Agent for the target WebLogic Server instance.

Once a successful security context is established, the web application - playing the Service Provider role - can consume it by relying on the security methods of the standard Servlet APIs.

The getUserPrincipal method can be used to return the javax.security.Principal object that contains the SSO user principal. The outcome of this method can be casted to the JOSSOUser class for the specific release of the Apache Tomcat Agent, allowing you to access SSO-specific properties, such as all the asserted claims for the user.

The isUserInRole allows you to assert if the remote user is granted the specified security role. Through this operation, it's possible to perform Role-based Access Control based on the supplied entitlement claims.

Within a business tier realized as Enterprise Java Beans, two approaches can be used for authorizing the caller: Declarative and Programmatic Authorization. With the declarative approach, access roles are defined in either the EJB descriptor or directly in the EJB class, using Java annotations. With the programmatic approach , the EJBContext.isCallerInRole method can be used to perform finer-grained access control. Both declarative and programmatic authorization can be used, building on the security context established by JOSSO.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the Web Server execution environment details :

Field Descriptions

Field

Description

Name

The unique identifier for the execution environment.

Description

A descriptive text for the execution environment.

Version

The Oracle Weblogic application server family.

Select "9.2" to define an execution environment element based on the Oracle Weblogic 9.2 family.

Select "10" to define an execution environment element based on the Oracle Weblogic 10 family.

Target Host

The host where the Oracle Weblogic 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 which hosts the artifacts of the Oracle Weblogic execution environment. The value for this field should correspond to that of the WL_HOME environment variable.

Remote JOSSO2 URL

The endpoint of the activation web service for a 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, if 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 you wish to deploy JOSSO example web applications onto the target execution environment. It is strongly recommended 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.

The Websphere Community Edition - also known as WASCE - is an open source application server developed by the Apache Software Foundation and distributed under the Apache license. It is the free edition of IBM WebSphere application server and is based on Geronimo.

JOSSO supports SSO-enabling JavaEE applications running under WASCE 2.1 . Both web and business layers can be SSO-enabled. For instance, within a 3 or n-tier setting, once the security context is established on the web tier, JOSSO will seamlessly propagate it to the potentially distributed business tier. A business tier realized using Enterprise Java Beans (EJB) - namely Session Beans - will then be able to leverage the security context by applying the EJB-specific access control rules in both declarative - through Java annotations - and programmatic form.

Establishing an activation connection between an SP and a Websphere Community Edition Execution Environment implies that the SP is a standard JavaEE application, hosted by a Websphere Community Edition Server instance.

Launching the activation on an Websphere Community Edition execution environment triggers the provisioning of the specific SSO Agent for the target instance.

Once a successful security context is established, the web application - playing the Service Provider role - can consume it by relying on the security methods of the standard Servlet APIs.

The getUserPrincipal method can be used to return a javax.security.Principal object, that contains the SSO user principal. The outcome of this method can be casted to the JOSSOUser class for the specific release of the Apache Tomcat Agent, allowing you to access SSO-specific properties, such as all the asserted claims for the user.

The isUserInRole allows you to assert if the remote user is granted a specified security role. Through this operation, it's possible to perform Role-based Access Control based on the supplied entitlement claims.

Within a business tier realized as Enterprise Java Beans, two approaches can be used for authorizing the caller : Declarative and Programmatic Authorization. In the declarative approach, access roles are defined in either the EJB descriptor or directly in the EJB class using Java annotations. In the programmatic approach, the EJBContext.isCallerInRole method can be used to perform finer-grained access control. Both declarative and programmatic authorization can be used, building on the security context established by JOSSO.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the Web Sphere execution environment details :

Field Descriptions

Field

Description

Name

The unique identifier for the execution environment.

Description

A descriptive text for the execution environment.

Target Host

The host where the Websphere Community Edition 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 Websphere Community Edition execution environment. The value for this field should correspond to that of the WASCE_HOME environment variable.

Remote JOSSO2 URL

The endpoint of the activation web service for a 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, if 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, to deploy JOSSO example web applications onto the target execution environment. It is strongly recommended to check this field, in order to verify that the Internet SSO setting works as expected, before engaging in SSO-enabling candidate business applications.

Internet Information Services (IIS) – formerly called Internet Information Server – is a web server application and set of feature extension modules, created by Microsoft, for use with Microsoft Windows.

In order to build the SP on a Windows IIS execution environment, you must define a Windows IIS Execution Environment element, and associate it with the SP.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the Windows IIS execution environment details :

Field Descriptions

Field

Description

Name

The unique identifier for the execution environment.

Description

A descriptive text for the execution environment.

Target Host

The host where the Windows IIS 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 Windows IIS installation.

Remote JOSSO 2 URL

The endpoint of the activation web service for a 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 case 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 to deploy JOSSO example web applications onto the target execution environment. It is strongly recommended to check this field, in order to verify that the Internet SSO setting works as expected, before engaging in SSO-enabling candiate business applications.

Apache Tomcat (or Jakarta Tomcat or simply Tomcat) is an open source servlet container developed by the Apache Software Foundation (ASF). Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run.

JOSSO supports SSO-enabling JavaEE web applications running under Apache Tomcat 5.0, 5.5 and 6.0 .

Establishing an activation connection between a SP and a Tomcat execution environment implies that the SP is a standard Java Web Application, hosted by an Apache Tomcat container.

Launching the activation on an Apache Tomcat Execution Environment triggers the provisioning of the SSO Agent for this web container.

Once a successful security context is established, the web application - playing the Service Provider role - can consume it by relying on the security methods of the standard Servlet APIs.

The getUserPrincipal method can be used to return a javax.security.Principal object that contains the SSO user principal. The outcome of this method can be casted to the JOSSO User class pertaining to the specific release of the Apache Tomcat Agent, allowing you to access SSO-specific properties, such as all the asserted claims for the user.

The isUserInRole allows you to assert if the remote user is granted the specified security role. Through this operation it's possible to perform Role-based Access Control based on the supplied entitlement claims.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the Apache Tomcat execution environment details :

Field Descriptions

Field

Description

Name

The unique identifier for the execution environment.

Description

A descriptive text for the execution environment.

Version

The Apache Tomcat web container family.

Select "5.0.x" to define an execution environment element based on the Apache Tomcat 5 family.

Select "5.5.x" to define an execution environment element based on the Apache Tomcat 5.5 family.

Select "6.0.x" to define an execution environment element based on the Apache Tomcat 6 family.

Target Host

The host where the Apache Tomcat web container 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 Tomcat execution environment. The value for this field should correspond to that of the CATALINA_HOME environment variable.

Remote JOSSO2 URL

The endpoint of the activation web service for a 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 case 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, to deploy JOSSO example web applications onto the target execution environment. It is strongly recommended to check this field, in order to verify that the Internet SSO setting works as expected, before engaging in SSO-enabling candidate business applications.

JBoss is a Java EE certified platform for developing and deploying enterprise Java applications, Web applications, and Portals. JBoss Application Server provides the full range of Java EE 5 features, as well as extended enterprise services including clustering, caching, and persistence.

The Web Server component of the JBoss Application Server is the JBoss Web Server. The JBoss Web Server is an enterprise-ready web server designed for medium and large applications, based on Apache Tomcat, providing a single deployment platform for Java Server Pages (JSP) and Java Servlet technologies, PHP, and CGI.

JOSSO supports SSO-enabling JavaEE applications running under JBoss 3.2, 4.0, 4.2 and 5.0 . Both web and business layers can be SSO-enabled. For instance, within a 3 or n-tier setting, once the security context is established on the web tier, JOSSO will seamlessly propagate it to the potentially distributed business tier. A business tier realized using Enterprise Java Beans (EJB) - namely Session Beans - will then be able to leverage the security context by applying the EJB-specific access control rules in both declarative - through Java annotations - and programmatic form.

Establishing an activation connection between a SP and a JBoss Execution Environment implies that the SP is a standard JavaEE application hosted by a JBoss Application Server.

Launching the activation on an Apache Tomcat Execution Environment triggers the provisioning of the specific SSO Agent for the target JBoss Application Server instance.

Once a successful security context is established, the web application - playing the Service Provider role - can consume it by relying on the security methods of the standard Servlet APIs.

The getUserPrincipal method can be used to return the javax.security.Principal object that contains the SSO user principal. The outcome of this method can be casted to the JOSSOUser class for the specific release of the Apache Tomcat Agent, allowing you to access SSO-specific properties, such as all the asserted claims for the user.

The isUserInRole allows you to assert if the remote user is granted the specified security role. Therefore, through this operation it's possible to perform Role-based Access Control based on the supplied entitlement claims.

Within a business tier realized as Enteprise Java Beans, two approaches can be used for authorizing the caller: Declarative and Programmatic Authorization. In the declarative approach access roles are defined in either the EJB descriptor or directly in the EJB class using Java annotations. In the programmatic approach , the EJBContext.isCallerInRole method can be used to perform finer-grained access control. Both declarative and programmatic authorization can be used, building on the security context established by JOSSO.

From the Palette, click in the "Execution Environments" drawer, and drag it to the preferred location within the Diagram Canvas.

Within the setup dialog, enter the JBoss execution environment details :

Field Descriptions

Field

Description

Name

The unique identifier for the execution environment.

Description

A descriptive text for the execution environment.

Version

The Redhat JBoss application server family.

Select "3.2.6" to define an execution environment element based on the Redhat JBoss 3.2.6 family.

Select "4.0.x" to define an execution environment element based on the Redhat JBoss 4.0 family.

Select "4.2.x" to define an execution environment element based on the Redhat JBoss 4.2 family.

Select "5.x" to define an execution environment element based on the Redhat JBoss 5 family.

Target Host

The host where the Redhat JBoss application 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 Redhat JBoss application server instance. The value for this field should correspond to that of the JBOSS_HOME environment variable.

Remote JOSSO 2 URL

The endpoint of the activation web service for a 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 case 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, to deploy JOSSO example web applications onto the target execution environment. It is strongly recommended 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.