JBoss.orgCommunity Documentation

Chapter 11. Overlord S-RAMP Implementation

11.1. Overview
11.2. Server
11.2.1. Description
11.2.2. Configuring
11.2.3. Configuring (EAP)
11.2.4. Security (Authentication)
11.2.5. Security (Authorization)
11.2.6. Extending: Custom ArtifactBuilder

The Overlord S-RAMP implementation strives to be a fully compliant reference implementation of the S-RAMP specification. This chapter describes the overall architecture of the implementation and also provides some information about how to configure it.

The S-RAMP repository Atom API is protected using standard web application security and JAAS on the backend. When deploying to an application server, security should be configured according to the specifics of the container. Typically the API would be protected by a simple BASIC authentication scheme, but in some more advanced configurations it would be appropriate to use OAuth or SAML Bearer Token authentication mechanisms.

When deploying into JBoss, the S-RAMP distribution adds a JBoss security domain named "overlord-jaxrs". This security domain is configured to accept either a username and password (standard BASIC authentication) or a SAML Assertion (bearer token auth). If invoking the Atom API directly, then typically BASIC authentication would be used. When invoking the Atom API from an application that has already authenticated the user in some way, then it is appropriate to use SAML. For example, the S-RAMP CLI application uses BASIC authentication when invoking the S-RAMP Atom API. The S-RAMP Browser (a web application) requires the user be authenticated into it, and thus is able to use SAML rather than propagate user credentials.

When using simple BASIC authentication, the security domain must be configured with a source of users and passwords. For example, in JBoss EAP this information can be configured by modifying the following files:


Alternative mechanisms can be used by making changes to the security domains configured in the JBoss configuration. For example:


The relevant section looks something like this:

<security-domain name="overlord-jaxrs" cache-type="default">
    <login-module code="RealmDirect" flag="required">
      <module-option name="password-stacking" value="useFirstPass"/>

For example, the RealmDirect (which passes through the authentication to the Application Realm) login module could be replaced with a LDAP login module.

As mentioned earlier in this guide, part of the S-RAMP specification is the concept of derived content. This happens when an artifact of a certain type is added to the S-RAMP repository. The server is responsible for creating relevant and interesting derived artifacts from it. For example, when an XML Schema (XSD) document is added to the repository, the server is responsible for automatically creating an artifact for every top level Element, Complex Type, Simple Type, and Attribute declaration found in the XSD.

The ArtifactBuilder contract allows integrations to define custom properties on the primary artifact, generate derived artifacts, and resolve relationships between the whole set. The Overlord S-RAMP implementation includes ArtifactBuilders for all of the logical models defined by the S-RAMP specification (e.g. WSDL, XSD, Policy). However, it also provides a mechanism that allows users to provide ArtifactBuilders for their own artifact types. This is done by performing the following steps:

The Overlord S-RAMP distribution comes with an example of how to write and package a custom builder - the demo is named s-ramp-demos-custom-artifact-builder. Also, see the Javadocs for the relevant classes.