Data WA Logo
Contact Us Help Centre
  /  
  1. Help Centre
  2. Logins & Security
  3. Shared Location Information Platform (SLIP) accounts
  /  How does SLIP’s authentication system work?

How does SLIP’s authentication system work?

Avatar
Data WA
  • Updated

SLIP Maps – maps.slip.wa.gov.au

When accessing a secure SLIP Map via a web browser (i.e. using Chrome, Edge or Firefox), a token-based authentication (SAML/OAuth) is used to allow single sign-on.

This means that your username and password are requested only once, then future connections use the token or cookie to allow access. Clearing your browser cache or history will remove these cookies and you will be prompted to login again. Using a private or incognito browser will not automatically log you in at future sessions, and is best practice when using a public computer.

SLIP Data Services – services.slip.wa.gov.au

When connecting via a desktop, GIS client such as QGIS, GAIA or ArcGIS do not support the single sign-on token options SAML or OAuth and therefore use Basic Authentication.

This means that your username and password must be sent with every request. Generally these client applications will store the username and password within the application.

If your organisation uses a proxy to connect to the internet you may need to enable Use proxy for web access. Check with your IT department for your organisation's proxy settings.

Your IT administrator may also have to allow the following domains through your organisations firewall:

“maps.slip.wa.gov.au”
“services.slip.wa.gov.au”
“token.slip.wa.gov.au”
“data-downloads.slip.wa.gov.au”
“direct-download.slip.wa.gov.au”

SLIP also provides Esri Token services, which are required for customers using secure data services in ArcGIS Online (AGOL). See https://token.slip.wa.gov.au/arcgis/rest/services.

SLIP Data Snapshots - direct-download.slip.wa.gov.au

The authentication system for SLIP Direct Download Links (the URL suitable for automating access to geospatial data snapshots) is based on the OAuth 2.0 Authorisation Code Grant - this is similar to the authorisation flow you will have used if you sign into a site using your Google or Facebook accounts. It's a redirect-based flow that exchanges your credentials for an authorisation code, which in turn is exchanged for your authorisation token that allows you to access snapshots. For a more in-depth explanation please see DigitalOcean's article An Introduction to OAuth 2.0.

Customised Authorisation Code Grant Type

SLIP's authentication for data snapshots is based on OAuth 2.0's Authorisation Code grant type, but has been customised slightly to permit use by automated systems and programmatic access.

Flow diagram showing the steps for SLIP’s Customised Authorisation Code Grant.

The above flow includes the following steps:

A&B: typically, the user (a human) presents their credentials to the system and their web browsers follows a series of redirects to exchange those credentials for an intermediate authorisation code, followed by the final authorisation token.

C&D: this involves only one step: the application presents a username and password login form to collect the SLIP user’s credentials and makes a POST request to the authorization server to exchange the password for an access token. Automated systems can opt-in to a basic access authentication by setting the Authorization header to Basic ZGlyZWN0LWRvd25sb2Fk. Below is the example of a POST request that the application makes.

POST /as/token.oauth2
Host: sso.slip.wa.gov.au
Content-type: application/x-www-form-urlencoded

grant_type=password
&username=SLIP Username
&password=SLIP Password

The POST parameters in this request are explained below.

  • grant_type=password - This tells the server we’re using the Password grant type.
  • username= - The SLIP username that you enter in the application.
  • password= - The SLIP password that you enter in the application.

The authorization server replies with an access token in the same format as the other grant types.

{
  "access_token": " 527i1TWEn9uzlfGCrzW1J92HILcq",
  "token_type": "bearer",
  "expires_in": 7200
}

E&F: the client requests the protected resource from the resource server and authenticates by presenting the access token. The resource server validates the access token, and if valid, serves the request. Automated systems can opt-in to a token authentication by setting the Authorization header to Bearer <Token> ZGlyZWN0LWRvd25sb2Fk.

Refer to our article How To: Download Geospatial Data Snapshots for examples of traversing this authentication flow in Python and FME.

Related articles