keycloak-scim/authorization_services/topics/enforcer/js-adapter.adoc

85 lines
4.8 KiB
Text
Raw Normal View History

2016-11-29 15:30:53 +00:00
[[_enforcer_js_adapter]]
==== JavaScript Integration
2016-06-22 20:22:28 +00:00
2017-08-28 12:50:14 +00:00
The {project_name} Server comes with a JavaScript library you can use to interact with a resource server protected by a policy enforcer.
This library is based on the {project_name} JavaScript adapter, which can be integrated to allow your client to obtain permissions from a {project_name} Server.
2016-06-22 20:22:28 +00:00
2017-08-28 12:50:14 +00:00
You can obtain this library from a running a {project_name} Server instance by including the following `script` tag in your web page:
2016-06-22 20:22:28 +00:00
```html
2017-04-03 14:33:32 +00:00
<script src="http://.../auth/js/keycloak-authz.js"></script>
2016-06-22 20:22:28 +00:00
```
Once you do that, you can create a `KeycloakAuthorization` instance as follows:
```javascript
var keycloak = ... // obtain a Keycloak instance from keycloak.js library
2016-06-22 20:22:28 +00:00
var authorization = new KeycloakAuthorization(keycloak);
```
The *keycloak-authz.js* library provides two main features:
2016-06-22 20:22:28 +00:00
2017-08-28 12:50:14 +00:00
* Handle responses from a resource server protected by a <<_enforcer_overview, {project_name} Policy Enforcer>> and obtain a requesting party token (RPT) with the necessary permissions to gain access to the protected resources on the resource server.
2016-06-22 20:22:28 +00:00
2017-08-28 12:50:14 +00:00
** In this case, the library can handle whatever authorization protocol the resource server is using: <<_service_entitlement_api, Entitlements>>.
2016-06-22 20:22:28 +00:00
2017-08-28 12:50:14 +00:00
* Obtain permissions from a {project_name} Server using the <<_service_entitlement_api, Entitlement API>>.
2016-06-22 20:22:28 +00:00
2017-08-28 12:50:14 +00:00
In both cases, the library allows you to easily interact with both resource server and {project_name} Authorization Services to obtain tokens with
permissions your client can use as bearer tokens to access the protected resources on a resource server.
2016-06-22 20:22:28 +00:00
===== Handling Authorization Responses from a Resource Server
2016-06-22 20:22:28 +00:00
2017-08-28 12:50:14 +00:00
If a resource server is protected by a policy enforcer, it responds to client requests based on the permissions carried along with a <<_enforcer_bearer, bearer token>>.
Typically, when you try to access a resource server with a bearer token that is lacking permissions to access a protected resource, the resource server
responds with a *401* status code and a `WWW-Authenticate` header.
2016-06-22 20:22:28 +00:00
The value of the `WWW-Authenticate` header depends on the authorization protocol in use by the resource server. Whatever protocol is in use, you can use a `KeycloakAuthorization` instance to handle responses as follows:
2016-06-22 20:22:28 +00:00
```javascript
var wwwAuthenticateHeader = ... // extract WWW-Authenticate Header from the response in case of a 401 status code
2016-06-22 20:22:28 +00:00
authorization.authorize(wwwAuthenticateHeader).then(function (rpt) {
// onGrant callback function.
// If authorization was successful you'll receive an RPT
// with the necessary permissions to access the resource server
2016-06-22 20:22:28 +00:00
}, function () {
// onDeny callback function.
// Called when the authorization request is denied by the server
2016-06-22 20:22:28 +00:00
}, function () {
// onError callback function. Called when the server responds unexpectedly
});
```
The `authorize` function is completely asynchronous and supports a few callback functions to receive notifications from the server:
2016-06-22 20:22:28 +00:00
* `onGrant`: The first argument of the function. If authorization was successful and the server returned an RPT with the requested permissions, the callback receives the RPT.
* `onDeny`: The second argument of the function. Only called if the server has denied the authorization request.
* `onError`: The third argument of the function. Only called if the server responds unexpectedly.
2016-06-22 20:22:28 +00:00
Most applications should use the `onGrant` callback to retry a request after a 401 response. Subsequent requests should include the RPT as a bearer token for retries.
2016-06-22 20:22:28 +00:00
===== Obtaining Entitlements
2016-06-22 20:22:28 +00:00
The keycloak-authz.js library provides an `entitlement` function that you can use to obtain an RPT from the server using the Entitlement API.
2016-06-22 20:22:28 +00:00
```json
authorization.entitlement('my-resource-server-id').then(function (rpt) {
// onGrant callback function.
// If authorization was successful you'll receive an RPT
// with the necessary permissions to access the resource server
2016-06-22 20:22:28 +00:00
});
```
When using the `entitlement` function, you must provide the _client_id_ of the resource server you want to access.
2016-06-22 20:22:28 +00:00
The `entitlement` function is completely asynchronous and supports a few callback functions to receive notifications from the server:
2016-06-22 20:22:28 +00:00
* `onGrant`: The first argument of the function. If authorization was successful and the server returned an RPT with the requested permissions, the callback receives the RPT.
* `onDeny`: The second argument of the function. Only called if the server has denied the authorization request.
* `onError`: The third argument of the function. Only called if the server responds unexpectedly.
2016-06-22 20:22:28 +00:00
===== Obtaining the RPT
2016-06-22 20:22:28 +00:00
If you have already obtained an RPT using any of the authorization functions provided by the library, you can always obtain the RPT as follows from the authorization object (assuming that it has been initialized by one of the techniques shown earlier):
2016-06-22 20:22:28 +00:00
```javascript
var rpt = authorization.rpt;
```