This is part 2 of my blog series about cloud architecture on SAP Cloud Platform. You can find the overview page here.
In this blog, I want to help you understand a topic that I experienced as potentially confusing for people who are new to SAP Cloud Platform and cloud architecture: The concept and difference between members, application users, and database users. As a warning: this blog is fairly theoretical. But sometimes, you cannot avoid to study theory before you can actually use it in practice. I will therefore try to keep it as understandable and interesting to read as possible.
When you are constructing your cloud landscape, you'll have to think about "where your users are coming from" and how to manage them. Depending on your applications and the way you use SAP Cloud Platform, different approaches make sense here. Due to the complexity of the topics, I will write multiple blogs about user management and concepts but before you can begin to plan your user management, you'll have to understand the general rules behind users on SAP CP.
As of today, there are multiple "types" of users on SAP CP which all have different purposes. It's very important to understand this differentiation because otherwise, you'll end up with an inconsistent user management approach. I typically distinguish three types of users (by the way, this is only my own "inofficial" naming scheme):
Later on, I will tell you where these types of users are typically provisioned from and which type of user can be used for which purpose. Although, for example, Members could be used to access applications, from my point of view, they should not be used for this in real productive environments. But first, let me explain the three user types:
You can refer to the official documentation for the definition and roles of Members. As you see from the documentation, members can either be administrators or support users, but also developers (use Web IDE, start and stop applications, make commits to repository, create new applications). Theoretically, you could also use members to access applications, but later on I will explain why this is a bad idea in productive scenarios from my point of view.
The second user type is the Application User. Those users are the end-users of your applications. Of course, you could also allow anonymous access to applications but I typically see that Application Users are either internal users of the company or external customers of the company that is creating the SAP CP application (or both in hybrid scenarios, wait for my next blog for a deeper insight on hybrid scenarios).
The third user type is the Database User. This user is located in your HANA database in the cloud. It is possible with App2AppSSO that you propagate the application user down from the application layer to the database layer and use the same user(name) for the application and the database (I assume that you have a Java or HTML5 frontend and a HANA backend which is the typical case). Technically though, those users will be different entities because the HANA user management in SAP CP is NOT integrated with the application user management nor the member management. This is an extremely critical thing to understand and leads us directly to the next topic that we have to understand: users can be provisioned from different sources ("identity providers").
Today, there are five different sources that could provide users into your HCP Sub-Accounts:
The first one is the SAP ID Service. This service is a global service from SAP that provides a huge amount of users worldwide (I think I heard 6 million users once but do not quote me on this). All S-Users, C-Users, but also SAP internal I-Users and D-Users are provided from the SAP ID Service. You can assume that as soon as you have one of these users, that this user is typically provided to most of the SAP web-applications (marketplace, SCN, support portal, … everything) via the SAP ID Service.
The second source of users is the SAP Cloud Identity Service Authentication (SCI). If you license the SAP Cloud Identity Service Authentication from SAP, you'll basically have a cloud user store that provides a public SAML endpoint. You can manage your users within this service and basically connect it not only to SAP CP but to any kind of application that uses SAML for authentication. At this point it's important to note that SAP CP itself does NOT have a "built-in" user management. It will always rely on other identity providers that provide users via the SAML protocol. Your SCI tenant could be one of them. By the way, the SAP ID Service (our first identity provider from the list) is basically a SCI tenant that is managed by SAP. As usual, SAP "eats its own dog food" and also users SCI to provide users to applications. But when you choose to license a SCI tenant yourself, you'll have full control about this user store (and not SAP, which only has full control about the SAP ID Service tenant)).
The third source of users is your Corporate Identity Provider. Typically, I see my customers either use LDAP, and Active Directory, a NetWeaver UME, or other SAP systems to manage their internal users. If you already have this identity provider in your company (most likely…), you should think about whether it would be a good idea to integrate SAP CP with these identity providers so you do not have to replicate the users in some external cloud identity provider such as SCI (there are pro and cons for this decision. Let me know whether you agree to my recommendation…).
The fourth source is an arbitrary SAML identity provider. Technically from SAP CP perspective, this identity provider is the same as the second one, but it's not coming directly from SAP. If you already have a third party identity provider that provides its users via the SAML protocol, you could think of reusing that provider by connecting it to SAP CP instead of licensing SCI additionally. At this point you can see that SAP is really serious about providing an open platform with SAP CP - no one forces you to use a certain identity provider. You should however make sure that your identity provider can also communicate group information via SAML assertion attributes. Otherwise, you'll not be able to tell which user belongs into which group (we will cover this in the next blogs in more detail).
The fifth and last source is the HANA user management from your HANA database within SAP CP. This is somewhat a special user source as it's only available within your HANA database. So if you have no HANA persistency service licensed, you'll not have that user management. People who have used HANA on-premise before will recognize this user management as it's the same as in your on-premise HANA. Basically for SAP CP, SAP is putting a fully equipped HANA database system into your cloud account so naturally, you'll also have the regular HANA user management in your CP.
At this point, probably you are a bit confused about the different types of users and the different types of identity providers. Relax, I'll now bring the two parts together and explain which user can be used for which purpose and later on, I will also give you my personal recommendations of what I think how you should use the users.
Look at the first two pictures again and now imagine that you overlay those pictures. You'll end up with a matrix in which we can now depict which type of user is provided by which source:
The green and red icons symbolize whether the user type can/should be provisioned from the respective identity provider. Studying the matrix in detail will bring you to the following conclusion:
Essentially, it really boils down to those three rules. Easy, isn't it? Well, as usual, you should consider a few details and issues in practice:
I hope those explanations already helped you in understanding the topic so that you can also explain it better to your customers. Of course, you can also find much of the information somewhere spread over the official documentations but I hope with this article you understood the topic in one read without extensive research in multiple documents. As always, let me know whether you found my blog useful! In the next blog, I will dive deeper in how you can actually manage your users with different identity providers and give you some tips of how to integrate them with SAP CP. See you there!
Cheers,
Jakob
In this blog, I want to help you understand a topic that I experienced as potentially confusing for people who are new to SAP Cloud Platform and cloud architecture: The concept and difference between members, application users, and database users. As a warning: this blog is fairly theoretical. But sometimes, you cannot avoid to study theory before you can actually use it in practice. I will therefore try to keep it as understandable and interesting to read as possible.
When you are constructing your cloud landscape, you'll have to think about "where your users are coming from" and how to manage them. Depending on your applications and the way you use SAP Cloud Platform, different approaches make sense here. Due to the complexity of the topics, I will write multiple blogs about user management and concepts but before you can begin to plan your user management, you'll have to understand the general rules behind users on SAP CP.
As of today, there are multiple "types" of users on SAP CP which all have different purposes. It's very important to understand this differentiation because otherwise, you'll end up with an inconsistent user management approach. I typically distinguish three types of users (by the way, this is only my own "inofficial" naming scheme):
Later on, I will tell you where these types of users are typically provisioned from and which type of user can be used for which purpose. Although, for example, Members could be used to access applications, from my point of view, they should not be used for this in real productive environments. But first, let me explain the three user types:
You can refer to the official documentation for the definition and roles of Members. As you see from the documentation, members can either be administrators or support users, but also developers (use Web IDE, start and stop applications, make commits to repository, create new applications). Theoretically, you could also use members to access applications, but later on I will explain why this is a bad idea in productive scenarios from my point of view.
The second user type is the Application User. Those users are the end-users of your applications. Of course, you could also allow anonymous access to applications but I typically see that Application Users are either internal users of the company or external customers of the company that is creating the SAP CP application (or both in hybrid scenarios, wait for my next blog for a deeper insight on hybrid scenarios).
The third user type is the Database User. This user is located in your HANA database in the cloud. It is possible with App2AppSSO that you propagate the application user down from the application layer to the database layer and use the same user(name) for the application and the database (I assume that you have a Java or HTML5 frontend and a HANA backend which is the typical case). Technically though, those users will be different entities because the HANA user management in SAP CP is NOT integrated with the application user management nor the member management. This is an extremely critical thing to understand and leads us directly to the next topic that we have to understand: users can be provisioned from different sources ("identity providers").
Today, there are five different sources that could provide users into your HCP Sub-Accounts:
The first one is the SAP ID Service. This service is a global service from SAP that provides a huge amount of users worldwide (I think I heard 6 million users once but do not quote me on this). All S-Users, C-Users, but also SAP internal I-Users and D-Users are provided from the SAP ID Service. You can assume that as soon as you have one of these users, that this user is typically provided to most of the SAP web-applications (marketplace, SCN, support portal, … everything) via the SAP ID Service.
The second source of users is the SAP Cloud Identity Service Authentication (SCI). If you license the SAP Cloud Identity Service Authentication from SAP, you'll basically have a cloud user store that provides a public SAML endpoint. You can manage your users within this service and basically connect it not only to SAP CP but to any kind of application that uses SAML for authentication. At this point it's important to note that SAP CP itself does NOT have a "built-in" user management. It will always rely on other identity providers that provide users via the SAML protocol. Your SCI tenant could be one of them. By the way, the SAP ID Service (our first identity provider from the list) is basically a SCI tenant that is managed by SAP. As usual, SAP "eats its own dog food" and also users SCI to provide users to applications. But when you choose to license a SCI tenant yourself, you'll have full control about this user store (and not SAP, which only has full control about the SAP ID Service tenant)).
The third source of users is your Corporate Identity Provider. Typically, I see my customers either use LDAP, and Active Directory, a NetWeaver UME, or other SAP systems to manage their internal users. If you already have this identity provider in your company (most likely…), you should think about whether it would be a good idea to integrate SAP CP with these identity providers so you do not have to replicate the users in some external cloud identity provider such as SCI (there are pro and cons for this decision. Let me know whether you agree to my recommendation…).
The fourth source is an arbitrary SAML identity provider. Technically from SAP CP perspective, this identity provider is the same as the second one, but it's not coming directly from SAP. If you already have a third party identity provider that provides its users via the SAML protocol, you could think of reusing that provider by connecting it to SAP CP instead of licensing SCI additionally. At this point you can see that SAP is really serious about providing an open platform with SAP CP - no one forces you to use a certain identity provider. You should however make sure that your identity provider can also communicate group information via SAML assertion attributes. Otherwise, you'll not be able to tell which user belongs into which group (we will cover this in the next blogs in more detail).
The fifth and last source is the HANA user management from your HANA database within SAP CP. This is somewhat a special user source as it's only available within your HANA database. So if you have no HANA persistency service licensed, you'll not have that user management. People who have used HANA on-premise before will recognize this user management as it's the same as in your on-premise HANA. Basically for SAP CP, SAP is putting a fully equipped HANA database system into your cloud account so naturally, you'll also have the regular HANA user management in your CP.
At this point, probably you are a bit confused about the different types of users and the different types of identity providers. Relax, I'll now bring the two parts together and explain which user can be used for which purpose and later on, I will also give you my personal recommendations of what I think how you should use the users.
Look at the first two pictures again and now imagine that you overlay those pictures. You'll end up with a matrix in which we can now depict which type of user is provided by which source:
The green and red icons symbolize whether the user type can/should be provisioned from the respective identity provider. Studying the matrix in detail will bring you to the following conclusion:
- Members are provisioned by the SAP ID Service ! ATTENTION: AS OF JANUARY 19, 2017, YOU CAN ALSO PROVISION MEMBERS FROM SCI AND POSSIBLY ALSO ADFS (VIA SCI). I HAVE NOT TESTED THIS YET, BUT ONCE I TRIED IT OUT MYSELF, THIS BLOG WILL BE UPDATED !
- Application users are provisioned by SAP Cloud Identity Authentication, a corporate identity provider, or a third party SAML identity provider
- Database users are provisioned by the HANA Database's user management
Essentially, it really boils down to those three rules. Easy, isn't it? Well, as usual, you should consider a few details and issues in practice:
- Members can only be provided by the SAP ID Service at the moment. So only S-/C-/D-/I-Users can be members of your SAP CP Sub-Accounts. There is currently no way to
- a) Provision SAP CP Members from another source, so if you want internal users of your company to be members of SAP CP Sub-Accounts (which is very likely as members are either administrators, developers, or support users), the users have to have an S-User.
- b) Integrate Member management with your corporate or cloud user management.
- This means that at the moment, for example, if you delete a user from your corporate user management, that user will still have his S-User for his SAP CP Member in your companies Sub-Accounts. A very important detail in off-boarding of external developers or colleagues who leave a company! Make sure to keep it in sync.
- Currently, there is no API to manage the Members of SAP CP Sub-Accounts. This also means that an integration into existing user management processes is not possible for Members. Until further notice, you'll have to manage Members in SAP CP Sub-Accounts manually. So if you introduce SAP CP at a new customer, make sure that you also plan to introduce SAP CP Member management processes at the customer.
- You can configure your Sub-Accounts' Web IDEs so that they can be used by Application Users as well. In that case, you could provision your developers partly also from your corporate user management. Why do I say partly? Because although this configuration covers the Web-IDE permission, it does not cover the ability to synchronize code to the git repository, start and stop applications, or change configurations on the SAP CP Sub-Accounts (which to a certain extend a developer might want to do). For those tasks, the developers will still need a SAP CP Member which is provided by the SAP ID Service. Because of this, I would only recommend this special Web-IDE configuration in scenarios where you can live with this restriction. An example for such a scenario would be development of Fiori Applications for an on-premise SAP system (Gateway). Developers can use the Web-IDE to check-out the source code from the ABAP repository of the backend (via Cloud Connector), work on the code, and deploy it back to the backend system. In this scenario, no Member roles are required so you can fully provision your developers from your corporate or cloud identity provider. Also, no code will be stored in the git repository in SAP CP. But for every other development scenario where your developers need Member roles, I would say this special Web-IDE configuration will most likely just add confusion to your landscape. If you want to know more, read this and this.
- Technically, it is possible to also access applications with users that are provided by the SAP ID Service. From my point of view, this should only be done for first tests but never in productive scenarios. As you cannot modify or delete users from the SAP ID Service, it can become more challenging to restrict access on your applications if you also allow access with those users. I would recommend to keep things simple and straight by using SAP ID Service users only for your Members and use cloud or corporate identity providers for your applications. I will give you more detail about the actual configuration/system setup in the next blog.
I hope those explanations already helped you in understanding the topic so that you can also explain it better to your customers. Of course, you can also find much of the information somewhere spread over the official documentations but I hope with this article you understood the topic in one read without extensive research in multiple documents. As always, let me know whether you found my blog useful! In the next blog, I will dive deeper in how you can actually manage your users with different identity providers and give you some tips of how to integrate them with SAP CP. See you there!
Cheers,
Jakob
- SAP Managed Tags:
6 Comments
