The following document refers to a generic inWebo SAML integration. Please, note that some prerequisites and/or steps may differ depending on SAML configuration of the Service Provider.
Security Assertion Markup Language (SAML) 2.0 is one of the most widely used open standard for authentication and authorizing between multiple parties.
The SAML workflow implies the following actors:
User → the actual human trying to authenticate and having metadata (identity information) attached to them.
Identity Provider (IdP) → the service that serves as a source of identity and that confirms user identity. Here, inWebo has the IdP role. InWebo authenticates users and returns identity information to the Service Provider.
For an inWebo SAML integration, inWebo can only be the Identity Provider.
Service Provider (SP) → the application that a user tries to access. The SP is the service that requests authentication and identity information about the user. The SP takes authentication responses from the IdP and uses the information to create sessions for the user.
Here is what a basic authentication flow may look like, with inWebo SAML connector set:
The user makes an access request to the SP.
The SP requests authentication from inWebo.
The user is redirected to inWebo to authenticate.
The user enters their PIN and validates. In back-end an OTP is generated by the user device (token web, desktop and mobile ) and sent to inWebo.
InWebo validates the OTP and authenticates the user.
InWebo sends a SAML assertion to the SP. It contains user information such as logins, identifiers, and other relevant attributes.
The SP grants the user access.
An inWebo service with administrator rights
The Service Provider (SP) Metadata
The configuration consists of an exchange of metadata between the SP and the IdP (inWebo): each provides its metadata to the other. Then, it is necessary to make sure that inWebo provides attributes that match with the attributes of the SP so that the authentication works.
Step 1: Create inWebo SAML connector
Login to your inWebo administration console.
Go to the Secure Sites tab.
In the "connectors” section, click on Add a connector of type… and select SAML 2.0.
Name your connector.
Click on Add to create the connector.
Step 2: Provide the inWebo metadata to the SP
You should provide the inWebo IdP metadata to allow your SAML instance to communicate with the connector. You can download inWebo metadata from the inWebo platform, in the connector’s settings. Depending on the SP configuration method, you will need to copy and paste the Issuer URL, the SSO URL and the Single Logout Service URL, or directly download the metadata in XML format or PHP format.
Step 3: Provide the SP metadata to inWebo
inWebo SAML 2.0 connector needs to know the metadata of your SAML Service Provider authentication instance to communicate with it.
In your inWebo administration console, go to the Secure Sites tab.
Edit the SAML 2.0 connector previously created.
Paste the Service Provider (SP) metadata.
Click on Update to save the configuration.
If your SP does not provide its metadata file, you will have to create your own XML file with the SP information.
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="___UPDATE_HERE___"> <md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> -----BEGIN CERTIFICATE----- MIID6DCCAtCgAwIBAgIEESJUGTANBgkqhkiG9w0BAQsFADCBqjELMAkGA1UEBhMC VVMxETAPBgNVBAgMCE5ldyBZb3JrMREwDwYDVQQHDAhOZXcgWW9yazEaMBgGA1UE CgwRS0VNUCBUZWNobm9sb2dpZXMxEDAOBgNVBAsMB1N1cHBvcnQxKzApBgkqhkiG 9w0BCQEWHHN1cHBvcnRAa2VtcHRlY2hub2xvZ2llcy5jb20xGjAYBgNVBAMMEUtF TVAgVGVjaG5vbG9naWVzMB4XDTIwMDcwMTEzMzI0NVoXDTM0MDMxMDEzMzI0NVow gaQxCzAJBgNVBAYTAlVTMREwDwYDVQQIDAhOZXcgWW9yazEaMBgGA1UECgwRS0VN UCBUZWNobm9sb2dpZXMxEDAOBgNVBAsMB1N1cHBvcnQxJzAlBgNVBAMMHktFTVAt VGVjaG5vbG9naWVzLVNBTUwtU2lnbmluZzErMCkGCSqGSIb3DQEJARYcc3VwcG9y dEBrZW1wdGVjaG5vbG9naWVzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAPA+E1EJJObvA9uyuJcsy7RPEn0xKMrcyxyaJaqqeDzigD3K4BvlIFMA Qt1Zf+iGI5BSLxx6b+lEcB7n41yovxFUNUvzoNWy/bsoZD+WLhbmV9IXFL64xoei QlroWO0YcZcsSsNi6nnVQG0SXXw2kJkFWYTT8YUnmrodo+/N3YS2sh10Vj5HchTw ur06r+R4rZr7dbI8NWnqaSnsv8mI5XlPlCP4pvN/RKxZLFv1jBlF0YVXZzRjDxtW VjsEY+l9ro96iZv96Qcig+vpwZWPzPuEvMDOcl0Mq3mbSknTvyisExsdOohIBC+g C3s0m+qy8k/MvYzqpQcNQTAmAIH5KlkCAwEAAaMaMBgwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwDQYJKoZIhvcNAQELBQADggEBAF8LKRz4a+C/psPC+Oq/LNXE1nt0 K3uv8EezTGJSnoRbjygpOM1XafInZv4Kb/boDie2FggVpwweWyNnEXModzkZCbdX yKAFqnll4n4yy6KpQlzZ/hCdVWXOlzp1cC0a7wqgnYCoiMRDmoDpje4rQONsVoEU SmX+N/pFgcLDxZyAVqJMWSOMXEv9CB+8T5CEDYr0ATarp3k3XoHwRcjTpoZ+PW/Y bLn2QBLB1YezUNK3OzvlOL4FEp1T1U2Wwj96zIAKf6gsBAqQLNl0XtvPEMJNPpts o+vZbl003StZ/c31TKEuoL1T1sqy7J9AdUmXLnIbdgRQZpVXO22VkCxHiQI= -----END CERTIFICATE----- </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="___UPDATE_HERE___"/> <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="___UPDATE_HERE___" index="0"/> </md:SPSSODescriptor> </md:EntityDescriptor>
You can download and modify the following XML file example to match your environment. → Download the SP metadata sample file
Make sure to configure:
entityID: use your SP Entity ID URL
Location(2 times): use your SP Entity ID URL
X509Certificate: copy and paste the SP certificate if needed
Step 4: Update the inWebo SAML connector
Now that the exchange of metadata between the SP and inWebo is done, you should configure the connector to make sure that inWebo provides attributes that match with the attributes of the SP.
In your inWebo administration console, in the connector settings, set the others parameters:
To protect users from attacks such as MFA fatigue/Push Bombing, we highly recommend setting the following parameters to "Yes": Browser Token Authentication and Push Authentication. This adds an authentication factor: an attacker will not be able to send push notifications to a user without an enrolled browser token. If users want to use push notifications with the inWebo Authenticator app to authenticate, they will need to enroll a browser token to trigger push notifications.
Browser Token Authentication
Browser Silent Authentication
This parameter only applies to inWebo Virtual Authenticator without PIN
SAML Assertion settings
SAML assertions contain all the information needed for a service provider to confirm user identity, including the source of the assertion, the time it was issued, and the conditions that make the assertion valid. You can configure some information that will be sent to the SP through the SAML Assertions. You should configure these settings to align the expectations between inWebo and the SP on the user identity that is communicated.
3- Connector Options
This parameter is not to be used (inWebo MFA does not manage sessions between applications)
The connector uses the value of the
Name ID format
This setting defines the format to use to transport the NameID. It must match the login known by the SP.
Name ID value
This setting defines the inWebo user property to use as the name ID value.
4- SAML Attributes
If the SP requires inWebo to send specific attributes in its SAML assertion, you should define here the attributes that will be added.
Choose a key name and set the value. The value can either be dynamic and related to the inWebo user (user login, user email...) or a static value (in this case the value is the same for all service users).
Click on Update.
Step 5: Configure the SP SAML settings
You should configure the SAML settings from your Service Provider platform. Service Providers all have their own unique methods of configuration. However, the following minimal set of configuration is needed for the identity provider to work with a service provider:
You should set the assertions: the source and format of this information will need to be configured. At the minimum, inWebo will send a NameID and some assertions about the user.
You should provide the inWebo IdP metadata to allow your SAML instance to communicate with the connector (See Step 2).
See the “Examples” sub-section below to see some third-party integration documentation.
Step 6: Create a secure site
In your inWebo administration console, go to the Secure Sites tab.
Click on Add a secure site of type… and select the SAML connector name you previously configured.
Set the Called URL to point to your SP Internet address.
The Called URL setting is only used to set a bookmark for the user on their Myinwebo portal, it has no impact on the security.
Click on Add to create the secure site.
Testing the authentication
To test your SAML authentication, go to the “Called URL”. You can retrieve the called URL from the inWebo console, in your Secure site settings.
To test the Push Authentication, be sure that the “Push Authentication” is set to Yes, in the connector parameters.
If the URL redirection is successful, but the authentication does not work, it may be an issue linked to attributes. Please check the connector settings and your SP SAML setting (See steps 4 and 5).
There are tools that can help you to debug. For example, “SAML-Tracer” is a web browser plugin for viewing SAML and WS-Federation messages sent through the browser during single sign-on and single logout.
Here are some inWebo documentations that refer to third-party integration, using the inWebo SAML 2.0 connector.
F5 BIG-IP, RADIUS and SAML integrations | F5BIG-IP,RADIUSandSAMLintegrations-ConfiguringInWeboSAMLauthenticationonaF5Big-IpAPM