NOTE: this blog posts series is intended for developers who have previous experience in developing CAP applications using SAP Business Application Studio, SAP BTP destinations, and the destination and XSUAA services.
Introduction
Secure cloud software should always rely on some sort of authentication and authorization mechanism to let users benefit from its functionality and protect it from attackers and/or malicious usage.
Based on such mechanism, users must first authenticate using login and password (safer systems even use two-factor authentication with some extra identity check technique, such as security tokens), so they can prove their identity, and, then, the application checks whether they are authorized to use its functionality and, if yes, which functionality – from the whole application – they are allowed to use: this is basically the definition of authentication (first part) and authorization (second part).
Authorizations are provided through some role-based mechanism through which a set of “roles” are assigned to users, granting them authorization to perform operations in the system (i.e. create, read, and/or update some data). So, a user with a role of, let’s say, “Viewer” would be allowed to access data in “read-only mode”, whilst a user with a role of “Admin” would also be allowed to write data to the system.
Therefore, it’s not unusual that, often times, the application should know who the authenticated user is (based on some user ID) and use that information to protect its functionality from unauthorized usage.
Most common example of such requirement, is an application that executes transactions triggered by the end-user (i.e. list orders, create, update and/or delete items, etc.). In such scenario, it would be nice to adjust the UI according to the user’s permissions (roles) and provide/display the appropriate controls which trigger only the authorized transactions.
And that’s why having information about the current authenticated user is definitely useful.
In this blog posts series we will present and discuss three different approaches to achieve such goal using the SAP Cloud Application Programming Model (in short, CAP).
Blog Posts in this Series
These are the four blog posts in this series for you to follow. The first one is the only prerequisite to the other three, so, after completing it, you can follow the others in the order that best suits your requirements:
- Setup project for development
- Directly from the UI (HTML5 app)
- Using the CAP request object
- Using the XSUAA API
Additional Resources
Here’s a list of resources to enhance your learning experience on this topic:
- Project-Specific Configurations ! CAP Documentation
- XSUAA in Hybrid Setup | CAP Documentation
- User API Service ! SAP Help Portal
- Authentication – req.user > cds.User class | CAP Documentation
- Access Administration Using APIs of the SAP Authorization and Trust Management Service | SAP Help Portal
Conclusion
After completing this blog posts series, you’ll have learned and experimented three different ways of fetching the authenticated user information on BTP using CAP. Depending on the requirements of your cloud project you can decide which one is the best fit for your end-users (you can even combine more than one).
Please, do not hesitate to submit your questions in Q&A in SAP Community: https://answers.sap.com/index.html
