You can configure your mine to accept delegated authentication from one or more identity resources which are protected by OAuth2 authentication. This involves sending the user to another site, having them sign in there, and being sent back to your InterMine with their credentials.
We are using the Apache OLTU library to help manage the authentication flow. This means that configuring some of the more common providers, such as Google, Facebook, Github and Microsoft is very simple. It also allows us to add any identity provider that meets certain minimum sanity requirements.
Warning Google has closed down their OpenID-2 based authentication solution in favour of OpenID Connect (OAuth2). If you want to use Google as an authentication provider you must use OAuth2.
Configuration is managed through adding values to the
You must register your application with the provider, giving them details of your application such as its name, and where it will be located. This varies from provider to provider - see this tutorial for a good guide to the registration process for a number of popular providers. For example, for Google, you will need a Google+ account and to visit the Google developer's console to create an application.
For ELIXIR, you will need:
an ELIXIR identity. Please register the ELIXIR ID here , if you don't already
register the new client here, using the New service page.
send an email to firstname.lastname@example.org in order to receive a form that you have to complete with additional information
For each application you will need to register the callback URI, which looks like:
or (if you use the legacy user interface):
webapp.path are the corresponding values from your configuration, and
PROVIDER is the name of the provider in all uppercase letters (as configured below). Google requires the
provider parameter as part of the URI, but other providers do not - you should check with each of them.
You can register 2 callback URIs if you want to provide both legacy and BlueGenes interfaces.
You will need to inform the InterMine system of the names of the providers which have been configured to work with your application. This should be a comma separated list of provider names. The values are case insensitive, and will be processed as upper-case values. E.g.:
To configure an OLTU supported provider (such as Github or Facebook), you simply need to define the client-id and client-secret you registered your application with, eg:
Warning All secrets, including these ones (especially the client-secret) MUST not be committed to version control or made publicly accessible. DO NOT add them to your web.properties file, but instead, add them to your mine.properties file (eg. ~/.intermine/MINE.properties).
To configure a custom provider, some other properties need to be provided. Taking AIP's araport system as an example, this can be configured thusly:
The URLs needed by the flow - contact your provider to find these out:
The scopes need to access the identity resource. This should include sufficient levels of permission to access the name and email of the authenticating user.
Information about the way the token endpoint functions. If the token endpoint expects parameters to be passed in the query-string use the value "QUERY", and if the endpoint expects the parameters to be passed in the message body provide the value "BODY":
Information about the way the token endpoint responds. If the token endpoint responds with
JSON, then provide the value "JSON", and if the endpoint responds with url-encoded form-data, then provide the value "FORM"
Information about the way the identity resource operates. If the resource expects the bearer token to be in the query parameters, provide the value "query", and if the bearer token is expected to be in the
Authorization header, pass the value "header".
The location of the identity resource. This must be a resource that can respond with
JSON. If query parameters are needed they should be included in the URL. An
Accept header will be provided with the value
Guides to interpreting the response from the identity resource. These are all optional.
InterMine supports completely automated delegated authentication, whereby a mediator may add a token that authenticates the user according to a chain of trust. This uses public-key cryptography to establish trust, and JWTs to transmit assertions.
All the configuration in this section can (and should) go in your
To enable this feature you need to do a couple of things:
InterMine needs access to public keys - this can mean creating a JKS key store (http://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html) with the certificate used to sign the JWTs - you should store the certificate against the alias with the same name as used in the
iss claim in the JWT. The keystore file should be saved as
keystore.jks.$release in the
~/.intermine directory, or moved as part of your release cycle to
MINE/resources/webapp/WEB-INF/ immediately prior to building your webapp.
If you do this, then you need to provide the following configuration:
|The password for this keystore.|
If your keystore has no password, then you do not need to set that property. See below for a quick guide to creating a valid keystore.
Instead of (or in addition to) creating a keystore, you can also provide keys in property files. Even though these are public keys, they are best included in your
~/.intermine/MINE.properties.release file, since they will be specific to a particular instance. Internally if you do not provide a keystore, an empty one will be created.
This is done by listing them as follows:
You can provide multiple keys and they will all be stored in the applications key-store under the given alias. Every key must have an alias, even if there is only one. If there is a problem with the key (it cannot be decoded, it is not valid, etc) it will be skipped by default, unless the following property is set to
true (in which case it will throw an error and prevent your web-application from starting):
BASE64_ENCODED_PUBLIC_KEY is the base64 encoding of the bytes of public key. Below is a sample program to illustrate how to do this in Java and python respectively:
Since this feature relies on public key cryptography, you need to tell the InterMine application which keys to use to verify which JWT tokens. This can be done with the following properties:
This property defaults to the most secure option,
NAMED_ALIAS, where only keys associated with the issuer of the token will be used to verify it. This means you will need to link the two. Each token must identify its issuer (with the
iss claim), you can map from that value to a key available to InterMine by providing the alias it is available as in the keystore. If you plan on accepting your own tokens, then you can provide the alias of your private key.
|The alias for the key certificate used to sign the JWT.|
If you use the
WHITELIST strategy, then you must provide the list of aliases that can be used to verify JWTs. All of them will be tried until one verifies successfully.
|The comma separated list of aliases to use.|
If you select the
ANY strategy, no further configuration is needed.
Multiple issuers can be supported by providing a key for each alias.
InterMine reads to claims about the end user from the JWT - who it identifies, and their email address. The email claim is non-standard, and needs to be configured. The subject claim can be overridden if the JWT tokens you are receiving have their subject identified in a different claim. To do so provide the following properties (in the following table,
$iss is the value of the
iss claim of the token):
|The name of the claim that provides the email of the subject. Defaults to |
|The name of the claim that provides the identity of the subject. This should be unique for each issuer. Not needed if the token provides the |
The following properties may also be important
|Used as the iss claim on any tokens the application issues itself. Also, if the tokens received include an |
|Used to gain access to the private key used by the application for signing its own tokens.|
|Used to retrieve the private key used by the application for signing its own tokens. To provide a private key you must configure a key store.|
An ant task is provided to make checking this (admittedly rather complex) set-up easier. To make use of it you should configure your keys as for production, acquire a valid JWT representative of one of the ones you expect to encounter in production, enter you webapp directory (
$MINE/webapp) and then call the following ant task:
If correctly set up, you should get a message printed to the console telling you who the token identifies.
You will need a Java Key Store to use public-key cryptography for security. To get started, you can use the following command to generate a
keystore.jks file with a new public/private key-pair:
The following command will allow you to add a certificate to your key-store:
This set-up would allow you to start accepting JWT tokens signed by the owner of
B.crt, which could be configured by making sure they are associated in your property files. So if the owner of
B.crt identified themselves with the
iss (issuer) claim
http://b.com, then you could link the certificate to the claim with the following property: