In the latest projects I have been working on there has been a need to mix authentication types when connecting to backend SAP systems via Odata Provisioning. Out of the box, this actually does not work if you have not got the right set up in place. I am writing this blog to help others navigate what is required to get this working.Additionally, this may not be the only way to get this working but I am simply showing one way I used to get this up and running.
What is the scenario I hear you say?? Well, maybe there are instances where you only need to read data and not perform any updates. Some applications can be read only - providing information to users so in this case Principal Propagation is actually overkill. The other reason is to allow more flexibility into the overall SAP Cloud landscape.
There are a few major steps involved including:
Each step will be covered in detail below.
Most customers I have worked with have set up the Principal Propagation security technique so the only Access control entry that will be maintained will be passing an X.509 certificate to the backend SAP system. This means that it is not compatible with your Basic Authentication requirements – as in this approach you are logging into the backend with specific credentials not with a certificate passed in via the logged on user.
The Principal Propagation related access control entry will look something like this. The key field here is the Principal Type field set to X.509 Certificate. Keep note on the virtual host name as well.
Figure:1 Principal Propagation Access control entry in Cloud Connector
So to get Basic Authentication working a new access control entry is required which will be a copy of the above except for the Principal Type being set to blank. This means that a certificate will NOT be passed from the Cloud Connector to the back-end SAP system for the specific logged on user.
Figure:2 Basic Authentication Access control entry in Cloud Connector
Notice also I am distinguishing the Virtual host name with a suffix of basic just to easily distinguish the back-end connections. This will be utilised in further steps.
At the end of this step there should be multiple access control entries set up. One for Principal Propagation and the other one for Basic Authentication.
Figure:3 Access control entries in Cloud Connector
Make sure to create the necessary resources for the new access control entry so you can access the Odata services and API's.
The next step is to check the Logon settings for the IWBEP service. I have had to modify this for pretty much every client that runs SAP Business Suite that I also want the Basic Authentication option to work for.
The change involves changing the Logon Procedure list of this service. Run transaction SICF and then double click to select the /sap/iwbep service. The following detail will appear.
Figure:4 /sap/iwbep SICF service definition
Make sure you navigate to the [Logon Data] tab page. If you scroll further down on this section you will see the current procedure list for logging in.
Figure:5 /sap/iwbep - Logon Procedure List - BEFORE
You should notice that the Basic Authentication option is 5th and in this case connection via OData provisioning will not work. To allow Basic Authentication from OData provisioning this Logon procedure needs to be modified so that the Basic Authentication is number 1.
Figure:6 /sap/iwbep - Logon Procedure List - AFTER
Change the order of the procedures so that the Basic Authentication is moved to the number 1 position.
Basic Authentication is now at the top of the Logon procedure list which is where it needs to be for this set up to work.
NOTE: This normally requires a transport so save the changes and make sure you migrate this along with all of your other project related developments.
The next step in the process is to make sure we have a SAP userid to use when using Basic Authentication. This userid still needs access like any other user to the specific OData services being executed as well as any additional security required to perform the read operations. Typically a good idea to also make this userid a Service userid.
The userid created here will be used in the Destination that will be created in the next step. The user of course should be valid and include all of the necessary security roles. This user especially needs the Fiori administration roles so that the relevant OData services can be registered successfully in OData provisioning.
Figure:7 SAP Technical user for BASIC Authentication
NOTE: If the registration fails in OData provisioning it means the user does not have enough security to perform the task.
The last step in the puzzle is to create Destinations. This will provide the ApptoAppSSO mechanism at the Subaccount level as well as the specific connection to the backend via the OData service destination. Multiple destinations are required here - one at the subaccount level and another one within the OData provisioning service.
This will be set up as AppToAppSSO as per the normal process when using OData provisioning.
Figure:8 Subaccount Destination for BASIC Auth example
This will reference a Destination in OData provisioning called BASIC_ERP_VENDORS. This is detailed below.
The OData provisioning destination will use Basic Authentication but a number of other settings need to be set including:
Figure:9 OData Provisioning Destination for BASIC Auth example
So once all of this is set up you can run the OData provisioning service and register and activate the relevant service.
First step of course is to select the Destination, in this case BASIC_ERP_VENDORS. You can see this has found services meaning the right security roles are assigned and connectivity to the backend has been established successfully.
Figure:10 OData Provisioning - Finding Services for Basic Auth destination
Second step is to select the service and register. As you can see above the services were found successfully and registered.
Figure:11 OData Provisioning - Registered service with Basic Auth destination
This concludes the steps to configure both Principal Propagation as well as Basic Authentication while utilising OData provisioning. Hopefully this helps others in the future.
Thanks for reading!! and feel free to leave Comments below or to Like to the blog itself!
What is the scenario I hear you say?? Well, maybe there are instances where you only need to read data and not perform any updates. Some applications can be read only - providing information to users so in this case Principal Propagation is actually overkill. The other reason is to allow more flexibility into the overall SAP Cloud landscape.
There are a few major steps involved including:
- Creation of new Access Control entries within the SAP Cloud Connector
- Modification of the IWBEP SICF service in the backend SAP ERP system
- Creation of a SAP Userid for connectivity from the Basic Auth destination
- Creation of Destinations within SAP Cloud Platform
Each step will be covered in detail below.
New Access Control entries in SAP Cloud Connector
Most customers I have worked with have set up the Principal Propagation security technique so the only Access control entry that will be maintained will be passing an X.509 certificate to the backend SAP system. This means that it is not compatible with your Basic Authentication requirements – as in this approach you are logging into the backend with specific credentials not with a certificate passed in via the logged on user.
The Principal Propagation related access control entry will look something like this. The key field here is the Principal Type field set to X.509 Certificate. Keep note on the virtual host name as well.
Figure:1 Principal Propagation Access control entry in Cloud Connector
So to get Basic Authentication working a new access control entry is required which will be a copy of the above except for the Principal Type being set to blank. This means that a certificate will NOT be passed from the Cloud Connector to the back-end SAP system for the specific logged on user.
Figure:2 Basic Authentication Access control entry in Cloud Connector
Notice also I am distinguishing the Virtual host name with a suffix of basic just to easily distinguish the back-end connections. This will be utilised in further steps.
At the end of this step there should be multiple access control entries set up. One for Principal Propagation and the other one for Basic Authentication.
Figure:3 Access control entries in Cloud Connector
Make sure to create the necessary resources for the new access control entry so you can access the Odata services and API's.
Updating the IWBEP SICF service
The next step is to check the Logon settings for the IWBEP service. I have had to modify this for pretty much every client that runs SAP Business Suite that I also want the Basic Authentication option to work for.
The change involves changing the Logon Procedure list of this service. Run transaction SICF and then double click to select the /sap/iwbep service. The following detail will appear.
Figure:4 /sap/iwbep SICF service definition
Make sure you navigate to the [Logon Data] tab page. If you scroll further down on this section you will see the current procedure list for logging in.
Figure:5 /sap/iwbep - Logon Procedure List - BEFORE
You should notice that the Basic Authentication option is 5th and in this case connection via OData provisioning will not work. To allow Basic Authentication from OData provisioning this Logon procedure needs to be modified so that the Basic Authentication is number 1.
Figure:6 /sap/iwbep - Logon Procedure List - AFTER
Change the order of the procedures so that the Basic Authentication is moved to the number 1 position.
Basic Authentication is now at the top of the Logon procedure list which is where it needs to be for this set up to work.
NOTE: This normally requires a transport so save the changes and make sure you migrate this along with all of your other project related developments.
Creation of a Basic Authentication SAP Userid
The next step in the process is to make sure we have a SAP userid to use when using Basic Authentication. This userid still needs access like any other user to the specific OData services being executed as well as any additional security required to perform the read operations. Typically a good idea to also make this userid a Service userid.
The userid created here will be used in the Destination that will be created in the next step. The user of course should be valid and include all of the necessary security roles. This user especially needs the Fiori administration roles so that the relevant OData services can be registered successfully in OData provisioning.
Figure:7 SAP Technical user for BASIC Authentication
NOTE: If the registration fails in OData provisioning it means the user does not have enough security to perform the task.
Creation of Destinations within SAP Cloud Platform
The last step in the puzzle is to create Destinations. This will provide the ApptoAppSSO mechanism at the Subaccount level as well as the specific connection to the backend via the OData service destination. Multiple destinations are required here - one at the subaccount level and another one within the OData provisioning service.
SubAccount Destination
This will be set up as AppToAppSSO as per the normal process when using OData provisioning.
Figure:8 Subaccount Destination for BASIC Auth example
This will reference a Destination in OData provisioning called BASIC_ERP_VENDORS. This is detailed below.
OData Provisioning Destination
The OData provisioning destination will use Basic Authentication but a number of other settings need to be set including:
- URL needs to match the Access control entry in the Cloud Connector as detailed above to enable Basic Authentication. From above this was https://qaerpbasic..... etc.
NOTE: I've used a Production example for the image.
- User that is detailed in the destination needs to be the SAP userid mentioned in the previous section. The password for this needs to be entered correctly.
Figure:9 OData Provisioning Destination for BASIC Auth example
So once all of this is set up you can run the OData provisioning service and register and activate the relevant service.
First step of course is to select the Destination, in this case BASIC_ERP_VENDORS. You can see this has found services meaning the right security roles are assigned and connectivity to the backend has been established successfully.
Figure:10 OData Provisioning - Finding Services for Basic Auth destination
Second step is to select the service and register. As you can see above the services were found successfully and registered.
Figure:11 OData Provisioning - Registered service with Basic Auth destination
This concludes the steps to configure both Principal Propagation as well as Basic Authentication while utilising OData provisioning. Hopefully this helps others in the future.
Thanks for reading!! and feel free to leave Comments below or to Like to the blog itself!
- SAP Managed Tags:
9 Comments
