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.
This document describes JWT for developers and the integration code required to use AAF Rapid Connect with their applications.
- Version: 2.0.0
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
JSON Web Token (JWT)
The following is sourced from the JWT specification.
The suggested pronunciation of JWT is the same as the English word "jot".
Relationship of JWTs to SAML Assertions
SAML 2.0 provides a standard for creating security tokens with greater expressiveness 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.
The user accesses your application and is provided access to any public content you wish them to see.
When authentication is required users need to be directed to a specific URL within AAF Rapid Connect unique to your application which is provided as part of registration. This can be achieved by:
- Presenting the unique URL as a link on your authentication page for the user to click on.
- Code within your application provides the user's browser with a 302 response directing the browser to the unique URL.
The user will authenticate to their institution's Identity Provider via their usual means. If the user's IdP is known in advance, it can be specified by appending its entityID to the unique Rapid Connect URL:
If no entityID is specified, the user will select their Identity Provider from a list of providers at the AAF Discovery Service.
- AAF Rapid Connect will validate the user's identity information and generate a unique and signed JWT (JWS) for your application using the secret you define when you register your service
- The generated JWT (JWS) will be sent via HTTP POST to the callback endpoint for your application which you define when you register your service.
The following claims are provided by AAF Rapid Connect:
- iss: Identifies the principal that issued the JWT. For AAF Rapid Connect this is always https://rapid.aaf.edu.au in the production environment, and https://rapid.test.aaf.edu.au in the test environment.
- iat: Identifies the time at which the JWT was issued.
- jti: Provides a unique identifier for the JWT that can be used to prevent the JWT from being replayed.
- nbf: Identifies the time before which the JWT MUST NOT be accepted for processing
- exp: Identifies the expiration time on or after which the JWT MUST NOT be accepted for processing
- typ: Declare a type for the contents of this JWT Claims Set in an application-specific manner in contexts where this is useful to the application
- aud: Identifies the audiences that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in audience claim. For Rapid Connect this is the value of your application's primary URL (provided as part of service registration)
- sub: Identifies the principal that is the subject of the JWT. For Rapid Connect this is the same value supplied as edupersontargetedid within https://aaf.edu.au/attributes as documented below.
- https://aaf.edu.au/attributes: Contains a set of personally identifiable information associated with sub as provided by the remote AAF connected identity provider.
Timestamps are defined by the specification as
IntDate values, which are a JSON numeric value representing the number of seconds from 1970-01-01T0:0:0Z UTC until the specified UTC date/time.
Integrating with AAF Rapid Connect
Before you get started
Before you get started with AAF Rapid Connect, you MUST meet all of the following high level requirements:
- You MUST be using HTTPS on your webserver for all JWT related endpoints. You SHOULD be using HTTPS for your entire application.
- The organisation which owns the service you're registering must be an existing AAF subscriber.
- You must have an existing account with AAF connected Identity Provider which you use to access AAF services.
The following AAF developed example code may assist your understanding when writing your own integration code:
1. Select a JWT library
To get started with AAF Rapid Connect integration select a suitable JWT library from the following for your application. These libraries will assist developers in quickly implementing JWT support. Libraries are not listed in any particular order and not endorsed by us. You should evaluate them individually to determine which best suits your needs. Found a useful JWT library not listed here? Please let us know about it.
- Devise and omniauth: https://github.com/jbarona/omniauth-jwt/tree/flexible-options. Contributed by James Barona from the South Australian Health and Medical Research Institute. A specific integration example is available within the following gist:https://gist.github.com/jbarona/7574703
- Example Perl code by Michael Lynch from EResearch Support Group, Information Technology Division, University of Technology, Sydney. https://github.com/spikelynch/Osiris/blob/master/Osiris/lib/Osiris/AAF.pm
Example Haskell application by Dr Carlo Hamalainen, Centre for Advanced Imaging, University of Queensland.
2. Create a secret
The first step in integrating your code is to compute a secret that will be shared between your application and AAF Rapid Connect for signing and verifying JWT.
Recommended secret generation method on *nix hosts, 32 characters long:
| LC_CTYPE=C tr -dc '[[:alnum:][:punct:]]' < /dev/urandom | head -c32 ;echo
This value should never be publicly disclosed. Once created be sure to store it securely. This value will be required during service registration.
3. Provide a web accessible endpoint
Your application MUST define a https endpoint which accepts a HTTP POST request.
The endpoint must acquire the data provided in the parameter assertion for further processing.
4. Validate the signed JWT (JWS) your application has received
Should any stage of the below validation fail your application MUST discard the token and present the user with a suitable error message.
- Verify that the signature for the signed JWT you have received is valid by using your locally stored secret value
- Ensure that the iss claim has the value https://rapid.aaf.edu.au when in the production environment, or https://rapid.test.aaf.edu.au when in the test environment.
- Ensure that the aud claim has the value of your application's primary URL (provided as part of service registration).
- The current time MUST be after or equal to the the time provided in the nbf claim.
- The current time MUST be before the time provided in the exp claim.
- Ensure that the value of the jti claim does not exist in a local storage mechanism of jti claim values you have accepted. If it doesn't (this MUST be the case) add the jti claim value to your local storage mechanism for protection against replay attacks.
All applications connecting to the AAF must adhere to all relevant AAF rules and policies. Prior to approving the connection of your service to the federation, the AAF may request to review your JWT related code and test your running endpoint to verify that an application's JWT handling conforms to the above requirements.
5. Make use of the user's personal information
Your application now has a fully verified JWT provided by AAF Rapid Connect.
By looking at the claim https://aaf.edu.au/attributes you will be able to access information about the user which most Research and Scholarly applications require. The following core AAF attributes SHOULD be available:
The following optional AAF attributes MAY be available at the discretion of the user's Identity Provider:
- edupersonprincipalname: The "NetID" of the person for the purposes of inter-institutional authentication.
- givenname: A person's first name or preferred name
- surname: A person's surname
- edupersonorcid: A person's ORCID identifier, if they have provided one.
You may also be provided with the auedupersonsharedtoken attribute if your use case requires it.For more information on auedupersonsharedtoken, see this support article.
You can now use this data to create a local account suitable for internal use by your application, for customisation and other purposes. It is RECOMMENDED that you use the data provided in either the JWT claim sub or the https://aaf.edu.au/attributes claim's edupersontargetedid field to uniquely identify users.
The JWT claim sub and the https://aaf.edu.au/attributes claim's edupersontargetedid field are always identical for Rapid Connect. The same value SHALL be provided for all subsequent visits to your application by each user. The full value of the field MUST be utilised to ensure your application uniquely identifies the remote user. Applications MUST NOT split this value based on the delimited bang segments.
The value of sub/edupersontargetedid is not able to correlate a user between services. For more details see http://wiki.aaf.edu.au/tech-info/attributes/edupersontargetedid.
Register your service
Access the AAF Rapid Connect website in the production federation or test federation and click on the button for "Register a service" which is on the right hand side in a blue colour, under the current version information. At that point you will be asked to select your Identity Provider and authenticate. Once this process is complete you will be returned to the service registration page.
To complete registration please provide:
- Organisation - The AAF subscribed organisation which is sponsoring this service.
- Name - A descriptive name for your service.
- URL - The primary URL of your application which users would enter in the browser to visit your application. This value is provided to your application as the aud claim.
- Callback URL - The secure URL within your application that AAF Rapid Connect should POST completed responses to. We described this endpoint as part of the integration steps above.
- Secret - Must be random and securely stored by the service. This value should never be publicly disclosed and is used by the service to verify signed tokens from AAF Rapid Connect. We generated this as part of the Integration Steps shown above.
If you're registering in the production federation
Once submitted the AAF will review and contact you with any questions. You should expect a response via email within 2 business days which will include a unique URL within AAF Rapid Connect for your application to start the authentication process as we discussed in Standard Flow above.
If you're registering in the test federation
Your application will be automatically approved. The completion screen will show the unique URL for your application to initiate login. You can use this immediately with your application to start the authentication process as we discussed in Standard Flow above.
To get help with AAF Rapid Connect, email AAF support at firstname.lastname@example.org.