Changes to service topics.
This commit is contained in:
parent
707e399281
commit
96962b2802
5 changed files with 13 additions and 16 deletions
|
@ -34,7 +34,6 @@
|
|||
... link:topics/service/authorization/whatis-obtain-aat.adoc[What is a AAT and How to Obtain It]
|
||||
... link:topics/service/authorization/authorization-api-aapi.adoc[Requesting Authorization Data and Token]
|
||||
.. link:topics/service/entitlement/entitlement-api.adoc[Entitlement API]
|
||||
... link:topics/service/entitlement/whatis-obtain-eat.adoc[What is a EAT and How to Obtain It]
|
||||
... link:topics/service/entitlement/entitlement-api-aapi.adoc[Requesting Entitlements]
|
||||
.. link:topics/service/protection/token-introspection.adoc[Introspecting a Requesting Party Token]
|
||||
.. link:topics/service/client-api.adoc[Authorization Client Java API]
|
||||
|
|
BIN
images/service/rs-uma-authorization-role.png
Normal file
BIN
images/service/rs-uma-authorization-role.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 63 KiB |
|
@ -1,6 +1,12 @@
|
|||
== What is a AAT and How to Obtain it ?
|
||||
|
||||
An *Authorization API Token* or *AAT* is a special OAuth2 Access Token with the scope *uma_authorization*.
|
||||
An *Authorization API Token* or *AAT* is a special OAuth2 Access Token with the scope *uma_authorization*. When you create an user, {{book.project.name}} automatically
|
||||
assigns a role _uma_authorization_ to the user. The _uma_authorization_ role is a _default realm role_ as you can see from this page.
|
||||
|
||||
.Default Role uma_authorization
|
||||
image:../../../images/service/rs-uma-authorization-role.png[alt="Default Role uma_authorization "]
|
||||
|
||||
An AAT means that a client application is allowed to query the server for user permissions.
|
||||
|
||||
Client applications can obtain an AAT from {{book.project.name}} just like any other OAuth2 Access Token. Usually, client applications obtain AATs after the user is successfully
|
||||
authenticated in {{book.project.name}}. By default the _authorizaton_code_ grant type is used to authenticate users and issue an OAuth2 Access Token to the client application acting on their behalf.
|
||||
|
@ -28,9 +34,4 @@ As a result, you will get the following response from the server:
|
|||
"not-before-policy": 0,
|
||||
"session_state": "3cad2afc-855b-47b7-8e4d-a21c66e312fb"
|
||||
}
|
||||
```
|
||||
|
||||
== About the uma_authorization scope
|
||||
|
||||
The *uma_authorization* scope can be created just like any other _realm role_. Or even as a _client role_. Once you created it, just grant this role to
|
||||
the users of your realm.
|
||||
```
|
|
@ -14,12 +14,12 @@ The easiest way to obtain entitlements for a specific user is using an HTTP GET
|
|||
|
||||
```bash
|
||||
curl -X GET \
|
||||
-H "Authorization: Bearer ${EAT}" \
|
||||
-H "Authorization: Bearer ${access_token}" \
|
||||
"http://localhost:8080/auth/realms/hello-world-authz/authz/entitlement/${resource_server_id}"
|
||||
```
|
||||
|
||||
[NOTE]
|
||||
When asking for entitlements using this endpoint, you need to provide the EAT (as a bearer token) representing user's identity and his consent to access authorization data on his behalf.
|
||||
When asking for entitlements using this endpoint, you need to provide the access_token (as a bearer token) representing user's identity and his consent to access authorization data on his behalf.
|
||||
|
||||
Where *${resource_server_id}* is the *client_id* registered with the client application acting as a resource server.
|
||||
|
||||
|
@ -39,7 +39,7 @@ authorization policies associated with all resources managed by the resource ser
|
|||
The entitlements endpoint also allows you to obtain user's entitlements for a set of one or more resources.
|
||||
|
||||
```bash
|
||||
curl -X POST -H "Authorization: Bearer ${EAT}" -d '{
|
||||
curl -X POST -H "Authorization: Bearer ${access_token}" -d '{
|
||||
"permissions" : [
|
||||
{
|
||||
"resource_set_name" : "Hello World Resource"
|
||||
|
@ -62,7 +62,7 @@ Unlike the GET version, the server is going to respond with a RPT holding the pe
|
|||
When asking for entitlements you can also specify the scopes you want to have access:
|
||||
|
||||
```bash
|
||||
curl -X POST -H "Authorization: Bearer ${EAT}" -d '{
|
||||
curl -X POST -H "Authorization: Bearer ${access_token}" -d '{
|
||||
"permissions" : [
|
||||
{
|
||||
"resource_set_name" : "Hello World Resource",
|
||||
|
@ -77,7 +77,7 @@ curl -X POST -H "Authorization: Bearer ${EAT}" -d '{
|
|||
=== Requesting Party Token or RPT
|
||||
|
||||
A RPT is basically a https://tools.ietf.org/html/rfc7519[JSON Web Token (JWT)] digitally signed using https://www.rfc-editor.org/rfc/rfc7515.txt[JSON Web Signature (JWS)].
|
||||
The token is built based on the EAT sent by the client during the authorization process.
|
||||
The token is built based on the access_token sent by the client during the authorization process.
|
||||
|
||||
When you decode a RPT you will see something like that:
|
||||
|
||||
|
|
|
@ -7,6 +7,3 @@ Unlike the _Authorization API_, the Entitlement API is not UMA-compliant and don
|
|||
|
||||
The purpose of this API is provide a more lightweight API for obtaining authorization data, where the client in possession of a valid
|
||||
OAuth2 Access Token is able to obtain the necessary authorization data on behalf of their users.
|
||||
|
||||
Any client application can access the Entitlement API endpoint, which requires a special OAuth2 access token called *Entitlement API Token* or *EAT*.
|
||||
|
||||
|
|
Loading…
Reference in a new issue