The following article details both SAML and Rapid connect services and explains the differences in each service to assist in ascertaining the best product to suit your needs.


If you have a service, intranet or authentication based services that you would like your organisation to access or would like to provide access to a service, then SAML and Rapid connect will provide the mechanism for your users to connect to a service or for your service to be accessible externally either, internationally, nationally or to a select group of participants.


What is SAML:

SAML is the oldest standard developed in 2001. SAML, pronounced “sam-el,” stands for Security Assertion Markup Language. It’s an open standard that provides both authentication and authorization.

SAML defines a principal, which is the end user trying to access a resource. There is a service provider, which is the web server that the principal is trying to access. And there is an identity provider, which is the server that holds the principal’s identities and credentials.

The SAML 2.0 specification defines assertions; protocols, which are assertion requests and responses; bindings, or how these requests and responses happen between the service provider and identity provider, using standard communication methods (e.g. HTTP POST); and profiles, which are combinations of assertions, protocols and bindings for various use cases, like SSO.

What is Rapid Connect:

The AAF Rapid Connect service allows the AAF to translate SAML assertions which are verified by a standard Shibboleth SP into JSON Web Token (JWT) which is more suitable for use by services with restricted environments or services with no need to access some of the more advanced parts of the AAF offering.


Rapid is simple to use but does have some restrictions as compared to a full SAML service that uses Shibboleth, SimpleSAMLphp or similar.

SAML 2.0 provides a standard for creating security tokens with greater expressivity and more security options than supported by JWTs. However, the cost of this flexibility and expressiveness is both size and complexity. SAML's use of XML and XML DSIG contributes to the size of SAML assertions; its use of XML and especially XML Canonicalization contributes to their complexity.

JWTs are intended to provide a simple security token format that is small enough to fit into HTTP headers and query arguments in URIs. It does this by supporting a much simpler token model than SAML and using the JSON object encoding syntax. It also supports securing tokens using Message Authentication Codes (MACs) and digital signatures using a smaller (and less flexible) format than XML DSIG.

Therefore, while JWTs can do some of the things SAML assertions do, JWTs are not intended as a full replacement for SAML assertions, but rather as a token format to be used when ease of implementation or compactness are considerations.


Technical background on SAML Shibboleth

More information on Rapid connect