Legacy API Gatekeeper#
Warning
We do not intend to add support for the legacy API gatekeeper to the customer portal.
Note
We do not recommend the legacy API gatekeeper for new solutions. Instead, use JWT token exchange managed through the customer portal.
However, data sources which provide data having multiple owners must at this time use the legacy API gatekeeper. Both the API and the clients which consume it have to use the dashboard for management.
The legacy API gatekeeper was the original functionality in Feide for protecting APIs. It enables you to make datasets available to third parties, with access control and authentication of clients and end users.
For applications where all functionality is separated into APIs, the gatekeeper can establish sessions and perform authentication between frontend and backend within your service.
However, each API call has to pass through the gatekeeper, in order to check if the call is allowed. If you use JWT token exchange instead, you avoid this bottleneck.
Registering an API with the legacy gatekeeper#
The gatekeeper works as an HTTP proxy adding support for authentication and authorization.
Example
Let us say you operate an API at https://api.example.org.
First, register a legacy API gatekeeper using the dashboard.
You choose an identifier for the API on the form <myapi>.dataporten-api.no.
This will be the hostname consumers of the API connect to.
You also register the URL where the gatekeeper can access your API endpoint. This endpoint must be secured by HTTPS.
Example of registering this gatekeeper using the dashboard:
Registering gatekeeper screenshot#
In the dashboard, you see an API Access pane for your gatekeeper with a username and password that the legacy API gatekeeper will use when accessing your API. The gatekeeper will use HTTP Basic Authentication to authenticate.
In the API Scopes pane, you set up the access policy for the basic scope and add subscopes if needed.
Third party clients that want to access your API through the legacy API gatekeeper register a regular OIDC/OAuth Feide client and request access to your API. The client will use OIDC/OAuth to connect to the gatekeeper, which in turn accesses your API.
Information for API implementors#
A request like this:
GET /foo/bar HTTP/1.1
Host: demoapi123.dataporten-api.no
Authorization: Bearer 12344567-1234-4998-1234-abbabababab
is passed on to your API like this:
GET /foo/bar HTTP/1.1
Host: api.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
X-Dataporten-clientid: 42b0c02e-0dda-4882-9da0-882a4b1abad6
X-Dataporten-userid: 76a7a061-3c55-430d-8ee0-6f82ec42501f
X-Dataporten-userid-sec: feide:andreas@uninett.no
X-Dataporten-gatekeeper: demoapi123
X-Dataporten-scopes: subscope1
X-Dataporten-token: abab6be7-8e87-4768-8026-e4266879a617
X-forwarded-for: 2001:700:1:21:ace8:7784:8016:8b0f
X-forwarded-proto: https
clientid is the client identifier of the requesting client.
userid is the authenticated end user’s Dataporten user identifier.
userid-sec is a list of secondary user keys, such as Feide ID.
It is comma separated. It is included whenever the API is allowed
access to at least one of the secondary user keys.
gatekeeper is the identifier of the API gatekeeper
scopes contains the authorized subscopes of the request. It is
included whenever there are any. It is comma separated.
token is an access token that the API can use to obtain information
about groups and more.
forwarded-for and forwarded-proto identify the address and protocol of
the requesting client.
Configuring your firewall#
All requests coming from the Feide legacy API gatekeepers come from these IP ranges and IP addresses:
2a05:d014:909:ad00::/562a05:d016:15b:5a00::/5613.49.2.13113.49.86.21713.49.194.14618.192.97.15818.193.183.24818.198.58.80
We recommend that you configure your API backend to only allow requests from these address ranges, so that you are not solely relying on the basic authentication described above.