@@ -19,23 +19,23 @@ FIWARE backends.
19
19
20
20
## User Guide
21
21
22
- The PEP Proxy GE is a backend component, without frontend interface. Therefore there is no need to provide a user guide.
22
+ The PEP Proxy GE is a backend component, without a frontend interface. Therefore there is no need to provide a user guide.
23
23
Please, take into account that this component checks authentication and authorization of users in FIWARE applications.
24
24
To create and manage users and applications and to configure roles and permissions for them, you have to use Identity
25
25
Management GE web interface. Please, check its User Guide in order to know how to proceed.
26
26
27
27
### Basic Use Case
28
28
29
- The basic use case is an scenario in which you have users of a frontend application that will access resources in a
30
- backend application. And you want to allow only FIWARE users to access that resources. The steps to setup this
29
+ The basic use case is a scenario in which you have users of a frontend application that will access resources in a
30
+ backend application. And you want to allow only FIWARE users to access that resources. The steps to set up this
31
31
environment are the following:
32
32
33
- - Deploy a PEP Proxy on top of your backend service. Now the endpoint of this service is the endpoint of the PEP Proxy
33
+ - Deploy a PEP Proxy on top of your backend service. Now, the endpoint of this service is the endpoint of the PEP Proxy
34
34
and you have to change the backend to other endpoint (may be in the same server but in other port). The PEP Proxy
35
35
will redirect the requests to the service.
36
- - Register you application in the IdM.
36
+ - Register your application in the IdM.
37
37
- With an OAuth2 library and the credentials obtained in the IdM for the application, implement an OAuth2 mechanism in
38
- your application. Thus, your users will be able to login in your application using their FIWARE accouts .
38
+ your application. Thus, your users will be able to log in to your application using their FIWARE accounts .
39
39
- When a user logs in into your application, IdM will generate an OAuth2 token that represents it. You have to save
40
40
this OAuth2 token to include it in the requests to your backend service (as an HTTP header).
41
41
- You have to send all the requests to your backend service to the endpoint in which is deployed the PEP Proxy.
@@ -45,7 +45,7 @@ environment are the following:
45
45
## Programmer Guide
46
46
47
47
PEP Proxy GE is designed to perform three levels of security for the backend REST APIs. Requests to proxy should be made
48
- with a special HTTP Header: X-Auth-Token or with the standar header Authorization: Bearer header. These headers contain
48
+ with a special HTTP Header: X-Auth-Token or with the standard header Authorization: Bearer header. These headers contain
49
49
the OAuth access token obtained from FIWARE IDM GE.
50
50
51
51
Example of requests:
@@ -69,7 +69,7 @@ configured. The available levels are:
69
69
- Level 1: Authentication PEP Proxy checks if the token included in the request corresponds to an authenticated user
70
70
in FIWARE.
71
71
- Level 2: Basic Authorization PEP Proxy checks if the token included in the request corresponds to an authenticated
72
- user in FIWARE but also if the roles that the user has allow it to access the resource specified in the request.
72
+ user in FIWARE but also if the roles that the user has allowed it to access the resource specified in the request.
73
73
This is based in the HTTP verb and the path.
74
74
- Level 3: Advanced Authorization PEP Proxy checks if the token included in the request corresponds to an
75
75
authenticated user in FIWARE but also other advanced parameters such as the body or the headers of the request.
@@ -100,7 +100,7 @@ If the validation success, PEP Proxy will redirect the request to the backend se
100
100
101
101
### Level 2: Basic Authorization
102
102
103
- Again the first step is to create a user and an application in FIWARE Account. In this case you have also to configure
103
+ Again, the first step is to create a user and an application in FIWARE Account. In this case you have also to configure
104
104
the roles and permissions for that user in that application. Please, see the User Guide of Identity Management in order
105
105
to know how to proceed.
106
106
@@ -110,7 +110,7 @@ to know how to proceed.
110
110
<p align =" center " >Figure 2: Basic Authorization</p >
111
111
112
112
[ Figure 2] ( #def-fig2 ) shows the architecture of this configuration. PEP Proxy checks if the access_token included in the
113
- request corresponds to an authenticated user in FIWARE Account. If the validation success the response includes the user
113
+ request corresponds to an authenticated user in FIWARE Account. If the validation succeeds, the response includes the user
114
114
information for that application. In this information is included the list of roles that the user has in the
115
115
application. And PEP Proxy checks with Authorization PDP GE if the user has the permissions to access the resource of
116
116
the request. This takes into account the HTTP verb and the path of the request.
@@ -129,7 +129,7 @@ that user in that application. Please, see the User Guide of Identity Management
129
129
<p align =" center " >Figure 3: Advanced Authorization</p >
130
130
131
131
[ Figure 3] ( #def-fig3 ) shows the architecture of this configuration. As this case is thought to check advanced parameters
132
- of the request such as the body or custom headers, it depends on the specific use case. So the programmer should modify
132
+ of the request, such as the body or custom headers, it depends on the specific use case. So the programmer should modify
133
133
the PEP Proxy source code in order to include the specific requirements.
134
134
135
135
With the desired parameters he has to create a XACML <Request > and send a request to Authorization PDP GE in order to
0 commit comments