Hi Andrés,
In SCP all authentication is delegated to what is called IdP (Identity Provider). This system will perform the authentication on behalf of SCP and will return a SAML assertion ticket containing the details about a user. Once authenticated, SCP will check if this user is authorized for the resources that are being called.
This is the reason why SCP has a members concept. Members aren't user objects. They don't contain passwords or any other information, other than the UserID.
Let's say you are a member of an account in SCP but you don't have any administration right on the cockpit. You may be able to load the initial page for the cockpit, but you aren't authorized to access any of its resources.
SCP comes with SAP's Identity Service configured as user persistence store. So when you try to login, SCP will load SAP ID Service for authentication. You are able to change that initial configuration via Trust menu on the cockpit so you are able to authenticate against a different IdP. Let's say you have your corporate LDAP service and you have already configured an IdP service for it such as Shibboleth or ADFS. In such case you simply register your corporate IdP via SCP's cockpit and you'll be able to perform login using your corporate ID and password.
SAP also offers you its own IdP as SaaS for corporate usage, called SAP Cloud Identity Authentication service which is capable of connecting SCP to your local LDAP server via SAP Cloud Connector - among other useful features such as managing user identities for companies that don't want to mix corporate users with cloud users.
Another aspect of this setup is that you may be able to pass on the user identity to your backend - what is called Principal Propagation. With that, an application running on SCP may consume a REST service in a local SAP-Gateway system via SAP Cloud Connector. And this consumption if configured for Principal Propagation will ensure that the user ID from SCP is sent as means for authentication for your SAP Gateway system.
So back to your original problem description: "My actual problem is that we need to see if the user in SCP exists in the backend system". With all of the above in mind, if you enable Principal Propagation, you don't have to worry about users being registered on the cockpit or not. I'm not saying this is a very simple configuration - as you said a lot of security concepts need to be understood first.
So you may have to first choose how you want people logging on to your SCP application and how services from your on-premise systems need to be called(authenticated). You may also need to figure out how you want to manage users altogether. Some may prefer to have different user/passwords in the cloud, but want to be able to map these users to back-end users - which is also possible.
Once you have all your prerogatives in place, you might need to subscribe to additional services, install some others or simply configure what you already have.
BTW: oAuth is another way to delegate authentication. So you may have your application configured in such a way that the logon procedure is based on a social network logon (such as Twitter or Facebook). You are able to see such a setup on SAP Community Network. Once you authorize SCN on Likedin to share on your behalf , you simply click on the Linkedin button, and click on Share - no login is performed. That's oAuth and SCP's support it so you can develop apps to use this kind of delegation.
Regards,
Ivan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.