We want to make integration as easy for our customers as possible. It means that we have to use the best capability for integration. We strongly believe in using the public APIs from SAP, but we have also found a good number of APIs that are much better for the Web API like enable Trace or to check how made changes to which IFlows. We have communicated with SAP and know they have a roadmap to resolve some of our limitations. We will make sure to migrate to use the public API, once the APIs improve but it is likely to be a process. We want to be able to support customer until then.
For now one of our big limitations is that we require SAP-users to be created without Universal ID. And SAP has a roadmap to require Universal ID on all users by the end of the year. The problem with Universla ID is that it requires Captia in some cases, so it is impossible to login using that approach in a scripted way.
This is released in our 2210 Release. See more here.
SAML authentication for Figaf user
We wanted to make the onboarding experience as fast as possible and still be able to support usage use of the Web APIs, we needed to find a secure solution for it that would be easy to configure.
We have looked at different IDP (IDentity Provider) providers but they all required a lot of extra work to install and configure. So we decided to create our own approach for a SAML provider because it is a fairly limited scope we need to cover. Thereby we could simplify the onboarding to a few steps to get the access we need and improve the security.
We would also not need to support 3-5 different IDP solutions that could be difficult to manage.
How it works
SAP BTP supports SAML as an authentication process, and we know a lot of you have already set it up
SAML works the following way.
- Users request access to a resource.
- Get a SAML IDP request with a location ID where the provider exists
- The client connects to the IDP
- Client need to provide credentials to authenticate with the IDP or reuse existing
- IDP return a signed SAML Response
- Client send the Signed SAML response to SAP
- SAP return an access token and some redirect to give access to the real system
Instead of calling an external IDP, Figaf generates and sign the SAML response with the private key of the certificate. There is no need to use external IDP.
Is it secure?
We have been pondering a lot on the topic and as we see it is just as secure as any saving credentials like Client id/secret in the database. You will be able to perform the same steps.
- The private key of the certificate is generated by the Figaf instance and is saved in encrypted format in the database.
- The private key never leaves the Figaf server.
- If a user gets access to the database and fetches the private key, the user will need to decrypt the key using some of the Figaf code.
- If users get access to decrypted private key is a pretty complicated process to use it for authentication.
- If users have access to the database, it will be easier to use client id and secret, they are encrypted in the same way.
You should keep your Figaf Database private like for all other important databases.
If you have some concerns, please write to [email protected]
We have tried to make it as smooth to install as possible with as few steps as possible.
In the IDP
You will need to create service keys for both the public API and for the message sent if you need to test messages on the platform.
Step 1: Download SAML Metadata from your SAP Cockpit:
Step 2: Copy value related to <md:AssertionConsumerService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=
Step 3: Open Agent Dialog and enable Use custom IdP checkbox. Paste SSO Url from the previous step. Save the Agent
Step 4: Generate Entity Descriptor for the Agent:
Step 5: Go back to the SAP Cockpit and upload this file as a new Trust configuration:
Step 6: Add Role collection mappings for the IdP: PI_Administrator, PI_Business_Expert, PI_Integration_Developer.
Step 7: If Figaf now try to check connection by pressing Test Connection
Step 8: After you have validated the process work, you can remove the check mark for “Available for User Logon”. This way, you will not receive the request to login.
We hope that work together with SAP to improve the APIs to fit our needs so we can get away from this complicated logic. Once the API improves, we will remove the need for using the Web API and retire the usage.
The current process can be a little problematic to set up, so we probably will create some guide process to add an Integration Suite Agent. And then also configure the correct API keys. One idea could also be to use the option to give users access to the relevant Cloud Integration tenants, but I would rather have people using a real IDP to resolve the need. It is possible we can add some value to the process.