# An Identity Model for Providing Inclusive Services and Applications
## 4 Proposed Model
### Advanced Architecture  
In complex scenarios where services need to include access control checks for determining which users can access the exposed resources, the whole IAACaaS model can be integrated in the proposed architecture. For managing access control policies, IAACaaS defines a set of rules that are composed by a target, an effect and a condition. These rules serve to create permissions and the permissions are grouped in rolesT. Taking advantage of the application-scoped feature of IAACaaS, roles and permissions can be defined in the scope of a service or application. Figure 3 shows the details of the integration of IAACaaS with our proposed architecture. The resources exposed by the service are typically provided by its back-end component (Service Backend). Apart of the IdM, the following components are needed as part of the Identity and Access Control Management (IAM) Infrastructure:  
Figure 2: Basic flow. * Policy Administration Point (PAP): Policies are set of rules and rules consist on a target (typically a resource), an effect (for instance allow/deny) and a condition [48]. In our proposal, rules are used to create _permissions_, where the target is an action (specified by an HTTP verb) and a resource of the service (specified by an HTTP path). More complex policies may be also defined, using the policy-description language. On the other hand, roles are sets of permissions, to allow developers to assign more than one permission at once. Service administrators define permissions, roles and their relationships in the PAP. * The Policy Enforcement Point (PEP): The PEP is the component that uses the access token (previously obtained by the user from the IdM) to retrieve the roles associated to the user from the IdM. Using these roles, the PEP sends the authorization check to the PDP. * The Policy Decision Point (PDP): The PDP receives an authorization check request from the PDP, retrieves the policies associated to those roles from the Policies DB and decides if a user that owns those roles has the required grants to perform the requested action in the requested resource. Summarizing, roles, permissions and their relationships are defined in the Policy Administration Point (PAP) and assigned to users in the IdM. As explained before, roles are assigned to users in the scope of the service, so a given user may have different roles depending on the application. During an authorization check, the Policy Enforcement Point (PEP) is the entity that uses the access token included in the requests sent from the application to the back-end to retrieve from the IdM the roles assigned to the User. Using this architecture, different levels of security can be achieved:  
1. Authentication: This level of security allows the access to the protected resource to every user with an active account in the IdM. In this case, the PEP just checks if the token included in the request is valid sending a validation request to the IdM. 2. Basic authorization: This level of security allows the access to the protected resource depending on the roles users have. The check is performed based on the action (defined by an HTTP verb) the user wants to perform in an specific resource (defined by an HTTP path). During the check to validate the token, the PEP obtains the roles associated to the user (being a role a set of permissions) and sends a new request to the PDP, that decides if those roles permit the execution of the requested action in the resource. For taking the decision the PDP fetches the policies from the Policies DB. Figure 3: Advanced architecture with access control. Advanced authorization: In this case, not only the action and the resource (HTTP verb and path respectively) are checked bu also other advanced parameters such as the body or the headers of the requests. To perform the check, a custom XACML policy request is sent to the PDP. Figure 4 shows the detail about how authorization checks are performed using this architecture. The first steps are the same than in the basic flow explained above.