JBoss.orgCommunity Documentation
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 server implementation is a conventional Java web application (WAR). The following technologies are used to provide the various components that make up the server implementation:
The UI is configured with numerous properties in the Wildfly/EAP standalone/configuration/standalone-full.xml file under the urn:jboss:domain:overlord-configuration:1.0 subsystem. For example:
<subsystem xmlns="urn:jboss:domain:overlord-configuration:1.0">
<configurations>
<configuration name="sramp-ui">
<properties>
<!-- The location of the S-RAMP server's Atom API -->
<property name="s-ramp-ui.atom-api.endpoint" value="http://localhost:8080/s-ramp-server" />
<!-- Whether or not to validate the S-RAMP server endpoint when connecting to it -->
<property name="s-ramp-ui.atom-api.validating" value="true" />
<!-- The authentication provider to use when connecting -->
<property name="s-ramp-ui.atom-api.authentication.provider" value="org.overlord.sramp.ui.server.api.KeycloakBearerTokenAuthenticationProvider" />
</properties>
</configuration>
</configurations>
</subsystem>The S-RAMP Browser is protected using web application security mechanisms configured in the WARs' web.xml.
By default, the UI uses single-sign-on (SSO) as the actual authentication mechanism. The SSO is provided via integration with the Keycloak framework. The actual web.xml configuration uses a standard basic security-context, but SSO is provided under-the-hood.
The security domain is configured to accept either a username and password (standard BASIC authentication) or a bearer token. 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 the bearer token as a request header ("Authorization", "Bearer " + bearerToken). 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 the bearer tokens rather than propagate user credentials.
The app uses a Keycloak realm named artificer, which you’ll see used in standalone-full.xml's Keycloak subsystem resources. See Getting Started for more info.
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.