2020-05-14 23:29:41 +02:00
|
|
|
|
WebServices / API
|
|
|
|
|
=================
|
|
|
|
|
|
|
|
|
|
Presentation
|
|
|
|
|
------------
|
|
|
|
|
|
|
|
|
|
WebServices and API are mostly requested by an application, and not the
|
|
|
|
|
end-user itself. In this case, you can not rely on LL::NG standard
|
|
|
|
|
Handler to protect the webservice, as it will expect a cookie, which is
|
|
|
|
|
not defined in the application requesting the service.
|
|
|
|
|
|
|
|
|
|
LL::NG offers several solutions to protect this kind of service.
|
|
|
|
|
|
|
|
|
|
ServiceToken Handler
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
Two Handlers will be used:
|
|
|
|
|
|
|
|
|
|
- The frontal Handler that will protect the web application, and will
|
|
|
|
|
forge a specific token
|
|
|
|
|
- The backend Handler that will protect the web service, and will
|
|
|
|
|
consume the token
|
|
|
|
|
|
|
|
|
|
See :doc:`ServiceToken Handler documentation<servertoserver>`.
|
|
|
|
|
|
|
|
|
|
OAuth2 endpoints
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
We suppose here that LL::NG is acting as
|
|
|
|
|
:doc:`OpenID Connect provider<idpopenidconnect>`. The web application
|
|
|
|
|
will then be able to get an access token from LL::NG. This token could
|
|
|
|
|
be sent to the webservice that can then validate it against LL::NG
|
|
|
|
|
OAuth2 endpoints.
|
|
|
|
|
|
|
|
|
|
UserInfo
|
|
|
|
|
~~~~~~~~
|
|
|
|
|
|
|
|
|
|
You can use the UserInfo endpoint, which requires the access token to
|
|
|
|
|
deliver user attributes.
|
|
|
|
|
|
|
|
|
|
For example:
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
curl \
|
|
|
|
|
-H "Authorization: Bearer a74d504ec9e784785e70a1da2b95d1d2" \
|
|
|
|
|
https://auth.example.ccom/oauth2/userinfo | json_pp
|
|
|
|
|
|
2020-05-21 15:13:24 +02:00
|
|
|
|
.. code-block:: javascript
|
2020-05-14 23:29:41 +02:00
|
|
|
|
|
2020-05-18 09:56:39 +02:00
|
|
|
|
{
|
|
|
|
|
"family_name" : "OUDOT",
|
|
|
|
|
"name" : "Clément OUDOT",
|
|
|
|
|
"email" : "clement@example.com",
|
|
|
|
|
"sub" : "coudot"
|
2020-05-14 23:29:41 +02:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Introspection
|
|
|
|
|
~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Introspection endpoint is defined in `RFC
|
|
|
|
|
7662 <https://tools.ietf.org/html/rfc7662>`__. It requires an
|
|
|
|
|
authentication (same as the authentication for the token endpoint) and
|
|
|
|
|
takes to access token as parameter.
|
|
|
|
|
|
|
|
|
|
For example:
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
curl \
|
|
|
|
|
-H "Authorization: Basic bGVtb25sZGFwOnNlY3JldA==" \
|
|
|
|
|
-X POST -d "token=a74d504ec9e784785e70a1da2b95d1d2" \
|
|
|
|
|
https://auth.example.com/oauth2/introspect | json_pp
|
|
|
|
|
|
2020-05-21 15:13:24 +02:00
|
|
|
|
.. code-block:: javascript
|
2020-05-14 23:29:41 +02:00
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
"client_id" : "lemonldap",
|
|
|
|
|
"sub" : "coudot",
|
|
|
|
|
"exp" : 1572446485,
|
|
|
|
|
"active" : true,
|
|
|
|
|
"scope" : "openid profile address email phone"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OAuth2 Handler
|
|
|
|
|
--------------
|
|
|
|
|
|
|
|
|
|
We also suppose here that LL::NG is acting as
|
|
|
|
|
:doc:`OpenID Connect provider<idpopenidconnect>`. But the webservice
|
|
|
|
|
will be protected by the OAuth2 Handler and will just have to read the
|
|
|
|
|
HTTP headers to know which user is connected.
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
curl \
|
|
|
|
|
-H "Authorization: Bearer a74d504ec9e784785e70a1da2b95d1d2" \
|
2020-05-18 09:56:39 +02:00
|
|
|
|
https://oauth2.example.ccom/rest/myapi
|
2020-05-14 23:29:41 +02:00
|
|
|
|
|
2020-05-21 15:13:24 +02:00
|
|
|
|
.. code-block:: javascript
|
2020-05-14 23:29:41 +02:00
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
"check" : "true",
|
|
|
|
|
"user" : "coudot"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
See :doc:`OAuth2 Handler documentation<oauth2handler>`.
|