CAPM Basics – Part 3

This is a continuation from Part 2: CAPM Basics – Part 2

Hello Colleagues,

In our previous blog, we were able to successfully deploy our application to cloud foundry. In this blog, we will learn about the XSUAA concept (eXtended Services for User Authentication and Authorization) and how to add restriction on entities based on user roles.

In our previous blog, when we added the XSUAA feature, an xs-security.json file was created which we did not modify. As a first step, we are going to define the scopes and role templates in our xs-security.json file.

{
“scopes”: [
{
“name”: “$XSAPPNAME.Viewer”,
“description”: “Viewer”
},
{
“name”: “$XSAPPNAME.Admin”,
“description”: “Admin”
}
],
“attributes”: [],
“role-templates”: [
{
“name”: “ViewerTemplate”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.Viewer”
]
},
{
“name”: “AdminTemplate”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.Admin”
]
}
]
}

Now we will attach these scopes to our entity as shown below. This will allow users with a Viewer Role template to only Read data from the entity, while users with a Admin Role template will be able to update the entity.

Now build your MTA project once more.

Do a “cf login” and deploy the “mtar” file to cloud foundry.

Once the deployment is successful, head over to your BTP Cockpit and expand the Roles section. You will find 2 new roles created by the above deployment.

Before we move any further, let us head over to Postman and see what changes the new restrictions have added to our entity.

When we now try to “GET” the data from “trainers” entity, we get a “403 Forbidden” response. This is because the entity is now expecting the user to be both authenticated and authorized to perform a read request.

Now head over to your BTP cockpit once again and create a new Role Collection as shown below and add the “Viewer” role and attach the same to your id.

Now come back to Postman and in the Authorization section of the request, change the Grant Type to “Password Credentials” as shown below. Provide the username and password in the respective fields (this username is the user to which we attached the role collection in the previous step).

Now request for a new token and send a “GET” request once more. This time the server returns back the data.

Now, try to POST some data to the same entity. What do we see? A “403 Forbidden” again. This is because our “Viewer” role is only granted “Read” access.

Go back to BTP Cockpit and add the “Admin” role to the role collection that we created.

Return to Postman, request a new token (as the previous token does not have the Admin Template) and try to POST the data again.

We are now able to successfully POST data to our entity.

This demonstrated how to use XSUAA to limit the scopes of users based on their authorization. Thank you for your patient reading. As always, in case of any feedback/questions please feel free to drop a comment below.

This is a continuation from Part 2: CAPM Basics – Part 2Hello Colleagues,In our previous blog, we were able to successfully deploy our application to cloud foundry. In this blog, we will learn about the XSUAA concept (eXtended Services for User Authentication and Authorization) and how to add restriction on entities based on user roles.In our previous blog, when we added the XSUAA feature, an xs-security.json file was created which we did not modify. As a first step, we are going to define the scopes and role templates in our xs-security.json file. {
“scopes”: [
{
“name”: “$XSAPPNAME.Viewer”,
“description”: “Viewer”
},
{
“name”: “$XSAPPNAME.Admin”,
“description”: “Admin”
}
],
“attributes”: [],
“role-templates”: [
{
“name”: “ViewerTemplate”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.Viewer”
]
},
{
“name”: “AdminTemplate”,
“description”: “generated”,
“scope-references”: [
“$XSAPPNAME.Admin”
]
}
]
} Now we will attach these scopes to our entity as shown below. This will allow users with a Viewer Role template to only Read data from the entity, while users with a Admin Role template will be able to update the entity.Now build your MTA project once more.Do a “cf login” and deploy the “mtar” file to cloud foundry.Once the deployment is successful, head over to your BTP Cockpit and expand the Roles section. You will find 2 new roles created by the above deployment.Before we move any further, let us head over to Postman and see what changes the new restrictions have added to our entity.When we now try to “GET” the data from “trainers” entity, we get a “403 Forbidden” response. This is because the entity is now expecting the user to be both authenticated and authorized to perform a read request. Now head over to your BTP cockpit once again and create a new Role Collection as shown below and add the “Viewer” role and attach the same to your id.Now come back to Postman and in the Authorization section of the request, change the Grant Type to “Password Credentials” as shown below. Provide the username and password in the respective fields (this username is the user to which we attached the role collection in the previous step).Now request for a new token and send a “GET” request once more. This time the server returns back the data.Now, try to POST some data to the same entity. What do we see? A “403 Forbidden” again. This is because our “Viewer” role is only granted “Read” access.Go back to BTP Cockpit and add the “Admin” role to the role collection that we created.Return to Postman, request a new token (as the previous token does not have the Admin Template) and try to POST the data again.We are now able to successfully POST data to our entity. This demonstrated how to use XSUAA to limit the scopes of users based on their authorization. Thank you for your patient reading. As always, in case of any feedback/questions please feel free to drop a comment below. Read More Technology Blogs by Members articles