This is part 4 of my blog series about cloud architecture on SAP Cloud Platform. You can find the overview page here.
Now that you have learned how you can provide identities to SAP CP applications by the help of different identity providers, I would like to focus on application architecture for this blog. Before starting to implement an application (that should be more than just a PoC), you should spend some time thinking about the application layers, services, and how those components can interact with each other in a manageable and secure manner.
I will focus on HTML5/Fiori frontends with HANA backends as this is a quite common combination. For Java, there are already enough resources available but especially for more loosely coupled frontend backend architectures, I think best practices are harder to find.
First of all, you probably know from beginners tutorials (e.g. the "personlist" application, link provided below) that your HANA database with the XS Engine and its web dispatcher can also act as a simple webserver. So technically, you could develop HTML5 frontends and HANA objects in the same repository in your HANA database and run everything in the XS Engine (this is what is done in the personlist tutorial and many others). Whereas for very quick and very dirty prototypes, this could be a way to structure your application, I would strongly recommend not to build any productive application like this. Especially not in a public cloud context such as SAP CP. In this blog, I will show you my approach for those kinds of applications and recommend you do the same in your projects!
Then, I find the versioning mechanisms of the HANA repository not as sophisticated as, for example, a git repository. So once you split your frontends and your backends, you can at least develop your frontends with the help of the git service in SAP CP. From what I have seen so far, most of the development (highest number of changes and commits), is done for the frontend. So by splitting, you can utilize git for most of the changes.
When looking under the hood, the web dispatcher of the XS Engine is also not as optimized for the typical tasks of a web server. When you create a new HTML5 application in the Cloud Cockpit, you'll have a much better performance under high load as if you let your database run the frontend.
Then, of course, you have much better separation and structure in your application. You could easier exchange a frontend or backend when both parts are loosely coupled. I have even seen customers who have all the application files in a single package of their HANA repository… not a good idea! Also, you'll later see that you can have permissions on package/folder level (declared in the application descriptor file). If you do not structure your application in a reasonable way, good luck with operating a clean security concept.
If you declare your permissions properly for your HTML5 application, the SAP CP Cloud Cockpit will automatically import those permissions and you can simply match them to application roles in the Cockpit:
If you only use the HANA layer, you will not have this at all. Also, your entire user management would be quite difficult to operate because you would have to connect your HANA Database with your identity provider… not an easy task for beginners.
Your HTML5 application in the Cloud Cockpit are also equipped with a neat feature for versioning and activation. This feature supports you in managing your releases with a simple UI and create versions from individual git commits.
If you release new versions or transport your application through your landscape (future tutorials), these functions are rather useful to, for example, transport the application first, create a new version, configure the version and prepare the go-live, and then activate the new version. From my experience, although this release mechanism still contains some manual steps, it results in quite relaxed go-lives of new versions. And if something fails, you can always activate a previous version again and fix the error while the previous version is running again.
So let's say you followed my advice of separating frontend and backend. The question now is how frontend and backend can communicate: Here, I would recommend using the SAP CP Connectivity Service. You should create a new destination and point it to your database. This destination could also point to a HANA database in a separate SAP CP Sub-Account. This way, you could share the database between applications in separate Sub-Accounts to save cost (of course, this results in more complex permission concepts).
For the destinations, you can choose between different authentication mechanisms because naturally, your web application has to authenticate itself against the database via the destination. My suggestion: if you can - from a security perspective - you can try to use basic authentication for this to keep it simple. Your application will have one (or multiple) destinations with technical users (= basic authentication) and connect to the database via the technical users. This means that your complete permission concept is handled in the frontend and configured via the SAP CP Cloud Cockpit, using the mapped roles/groups from your identity provider. A possible architecture would look like this:
The highlighted components contain user-related permission checks. Access to the application and the database connection(s) is restricted via roles. On the HANA database itself, only technical users execute services or procedures. However, this means that once your user has a valid session and is able to call the services provided by the HANA, he could in principle also access the service without the application front-end. Imagine you have all your validation in the frontend and a user is accessing a service by bypassing all your frontend checks... disastrous for write access and highly critical for read access to the database depending on the type of data you have in your DB!!
A more elaborate approach is to propagate the user from the frontend to the HANA database. Especially for write access to the database, you might want to keep track in a very detailed way of who added data to your database. Without propagating the user down to the database layer, you'll most likely have a hard time in making your database access bullet-proof from a data integrity perspective. You can configure your SAP CP Destination and your HANA database to use App2AppSSO, which will automatically create a new user in the HANA Database's user management (Link to tutorial provided below). So you don't have to import all users into the database but can create them dynamically at runtime. However, this approach has some pitfalls: The user that is created automatically is created with a default set of roles. You can change this set of roles and give the user the correct permissions, but you can only do it once per database. So if you have multiple applications on one database all using App2AppSSO, you cannot assign the proper permissions to that user without manual intervention. A way to mitigate this would be to use Multitenant Database Containers (MDC), but they are currently only available as a beta feature.
Also, the more users you create with App2AppSSO, over time, your user management will be filled with many potentially inactive users. You would have to make sure that the users are also removed again from the user management if you want to keep the database clean.
One way to mitigate all this is integrating your HANA database in the cloud with your existing identity provider (probably your corporate user management). Users that are deactivated here are typically also deactivated on the connected HANA systems. Via the cloud connector and the ODBC tunnel, you can integrate also your HANA Databases in HCP into your 'normal' on-premise HANA user management tools. A possible architecture for this approach could look like this:
Here, the user is propagated to the database and because of the fact that the user from the corporate identity provider is synchronized to the HANA Database, permissions can be assigned to user (groups) on database level additionally.
So I would recommend you investigate by yourselves whether the usage of technical users is sufficient for your application and if not, implement some form of principal propagation in order to avoid that the application user is bypassing your frontend permission concept.
In my next blog, we will look into how you can manage the permissions for the frontend in a secure way and integrate it with your corporate or cloud user management (users and groups). After that, we will dive deeper into the transport and lifecycle topics.
See you there! Cheers,
Jakob
Further information:
Personlist application
http://www.sap.com/documents/2015/08/96795550-5a7c-0010-82c7-eda71af511fa.html
Tutorial: App2AppSSO for HANA in SAP CP
https://blogs.sap.com/2016/03/21/principal-propagation-between-html5-and-sap-hana-xs-on-sap-hana-clo...
Now that you have learned how you can provide identities to SAP CP applications by the help of different identity providers, I would like to focus on application architecture for this blog. Before starting to implement an application (that should be more than just a PoC), you should spend some time thinking about the application layers, services, and how those components can interact with each other in a manageable and secure manner.
I will focus on HTML5/Fiori frontends with HANA backends as this is a quite common combination. For Java, there are already enough resources available but especially for more loosely coupled frontend backend architectures, I think best practices are harder to find.
First of all, you probably know from beginners tutorials (e.g. the "personlist" application, link provided below) that your HANA database with the XS Engine and its web dispatcher can also act as a simple webserver. So technically, you could develop HTML5 frontends and HANA objects in the same repository in your HANA database and run everything in the XS Engine (this is what is done in the personlist tutorial and many others). Whereas for very quick and very dirty prototypes, this could be a way to structure your application, I would strongly recommend not to build any productive application like this. Especially not in a public cloud context such as SAP CP. In this blog, I will show you my approach for those kinds of applications and recommend you do the same in your projects!
Then, I find the versioning mechanisms of the HANA repository not as sophisticated as, for example, a git repository. So once you split your frontends and your backends, you can at least develop your frontends with the help of the git service in SAP CP. From what I have seen so far, most of the development (highest number of changes and commits), is done for the frontend. So by splitting, you can utilize git for most of the changes.
When looking under the hood, the web dispatcher of the XS Engine is also not as optimized for the typical tasks of a web server. When you create a new HTML5 application in the Cloud Cockpit, you'll have a much better performance under high load as if you let your database run the frontend.
Then, of course, you have much better separation and structure in your application. You could easier exchange a frontend or backend when both parts are loosely coupled. I have even seen customers who have all the application files in a single package of their HANA repository… not a good idea! Also, you'll later see that you can have permissions on package/folder level (declared in the application descriptor file). If you do not structure your application in a reasonable way, good luck with operating a clean security concept.
If you declare your permissions properly for your HTML5 application, the SAP CP Cloud Cockpit will automatically import those permissions and you can simply match them to application roles in the Cockpit:
If you only use the HANA layer, you will not have this at all. Also, your entire user management would be quite difficult to operate because you would have to connect your HANA Database with your identity provider… not an easy task for beginners.
Your HTML5 application in the Cloud Cockpit are also equipped with a neat feature for versioning and activation. This feature supports you in managing your releases with a simple UI and create versions from individual git commits.
If you release new versions or transport your application through your landscape (future tutorials), these functions are rather useful to, for example, transport the application first, create a new version, configure the version and prepare the go-live, and then activate the new version. From my experience, although this release mechanism still contains some manual steps, it results in quite relaxed go-lives of new versions. And if something fails, you can always activate a previous version again and fix the error while the previous version is running again.
So let's say you followed my advice of separating frontend and backend. The question now is how frontend and backend can communicate: Here, I would recommend using the SAP CP Connectivity Service. You should create a new destination and point it to your database. This destination could also point to a HANA database in a separate SAP CP Sub-Account. This way, you could share the database between applications in separate Sub-Accounts to save cost (of course, this results in more complex permission concepts).
For the destinations, you can choose between different authentication mechanisms because naturally, your web application has to authenticate itself against the database via the destination. My suggestion: if you can - from a security perspective - you can try to use basic authentication for this to keep it simple. Your application will have one (or multiple) destinations with technical users (= basic authentication) and connect to the database via the technical users. This means that your complete permission concept is handled in the frontend and configured via the SAP CP Cloud Cockpit, using the mapped roles/groups from your identity provider. A possible architecture would look like this:
The highlighted components contain user-related permission checks. Access to the application and the database connection(s) is restricted via roles. On the HANA database itself, only technical users execute services or procedures. However, this means that once your user has a valid session and is able to call the services provided by the HANA, he could in principle also access the service without the application front-end. Imagine you have all your validation in the frontend and a user is accessing a service by bypassing all your frontend checks... disastrous for write access and highly critical for read access to the database depending on the type of data you have in your DB!!
A more elaborate approach is to propagate the user from the frontend to the HANA database. Especially for write access to the database, you might want to keep track in a very detailed way of who added data to your database. Without propagating the user down to the database layer, you'll most likely have a hard time in making your database access bullet-proof from a data integrity perspective. You can configure your SAP CP Destination and your HANA database to use App2AppSSO, which will automatically create a new user in the HANA Database's user management (Link to tutorial provided below). So you don't have to import all users into the database but can create them dynamically at runtime. However, this approach has some pitfalls: The user that is created automatically is created with a default set of roles. You can change this set of roles and give the user the correct permissions, but you can only do it once per database. So if you have multiple applications on one database all using App2AppSSO, you cannot assign the proper permissions to that user without manual intervention. A way to mitigate this would be to use Multitenant Database Containers (MDC), but they are currently only available as a beta feature.
Also, the more users you create with App2AppSSO, over time, your user management will be filled with many potentially inactive users. You would have to make sure that the users are also removed again from the user management if you want to keep the database clean.
One way to mitigate all this is integrating your HANA database in the cloud with your existing identity provider (probably your corporate user management). Users that are deactivated here are typically also deactivated on the connected HANA systems. Via the cloud connector and the ODBC tunnel, you can integrate also your HANA Databases in HCP into your 'normal' on-premise HANA user management tools. A possible architecture for this approach could look like this:
Here, the user is propagated to the database and because of the fact that the user from the corporate identity provider is synchronized to the HANA Database, permissions can be assigned to user (groups) on database level additionally.
So I would recommend you investigate by yourselves whether the usage of technical users is sufficient for your application and if not, implement some form of principal propagation in order to avoid that the application user is bypassing your frontend permission concept.
In my next blog, we will look into how you can manage the permissions for the frontend in a secure way and integrate it with your corporate or cloud user management (users and groups). After that, we will dive deeper into the transport and lifecycle topics.
See you there! Cheers,
Jakob
Further information:
Personlist application
http://www.sap.com/documents/2015/08/96795550-5a7c-0010-82c7-eda71af511fa.html
Tutorial: App2AppSSO for HANA in SAP CP
https://blogs.sap.com/2016/03/21/principal-propagation-between-html5-and-sap-hana-xs-on-sap-hana-clo...
- SAP Managed Tags:
2 Comments
