Single Sign-On (SSO) can be a big time saver for both users and administrators. With Single Sign-On users can log in to their Bynder portal with just one click. By implementing SSO, company employees won't need separate Bynder credentials to authenticate. When they're connected to your company network they can click the SSO login button on the login page of the portal to quickly log in.
SSO also allows you to create new user accounts automatically, which takes this manual task away from portal administrators. By setting up profile or group mapping you can ensure that a user account with the appropriate permission profile is created when a user logs in for the first time using SSO.
Discover the possibilities of SSO below and find out which standards and services we support.
Bynder supports the most common standards and services for SSO integration using Security Assertion Markup Language (SAML), for example, Active Directory Federation Services (ADFS), OKTA, Azure, Google SSO, and Oracle.
If you use LDAP, you need to enable your ADFS infrastructure to authenticate users whose identities are stored in LDAP. For more information, see:Configure AD FS to authenticate users stored in LDAP directories
If you want to use Microsoft Azure, see the link for the required integration steps: Tutorial: Azure Active Directory integration with Bynder.
Okta is a leading SSO provider that offers a reliable single sign-on service which integrates with all your web and mobile apps. Below you'll find an example setup you can use for setting up Okta on your side and our frequently asked questions for Okta. Read more about setting up Okta for Bynder here or check the most frequenly asked questions about Okta below.
What signing options are required by Bynder?
The SAML response must be signed.
What signing algorithm are supported by Bynder?
The RSA-SHA256 and RSA-SHA1 algorithms are supported, but Okta will default to the RSA-SHA256 algorithm since it's more secure.
Does Bynder support enabling force authentication?
We do not support configuring forceAuthn in the SAML request.
What is the default relay state URL?
This value can be left empty.
In our standard set up, we’ve created a post redirect to Microsoft ADFS. For this, we use SAML 2.0 with SAML 1.1 assertions. Validation of messages is done with a separate certificate (in pem/x509 format - exchanged together with the ADFS metadata of the identity provider) and we support ONLY message-signed assertions. We work with XML messages that send and decrypt binary data (base64-encoded deflated).
Follow the instructions below and provide your Onboarding Manager or Customer Success Manager with the information we need to set up SSO for your portal.
Configure ADFS for SSO with Bynder. If you use groups in ADFS, you need additional configuration to pass the permissions to Bynder. See how to do it for Windows Server: Implement a trust between Enterprise ADFS 3.0 on Windows Server 2012R2 .
-
Decide on the look and feel and default behavior of your Bynder login page. Contact your Onboarding Manager or Customer Success Manager and provide them with the customizations and features you would like to have implemented.
Domain Whitelist
You can whitelist certain email domains, so that users who login for their first time can click the SSO login button to create an account. Users with a whitelisted domain will be automatically granted access and assigned to the mapped profile. If a default profile has been set up and no mapped profile is sent during the SSO request, the user will be assigned to the default profile.
Default profile
If no profile mapping is set up or sent during the SSO request, the users will be assigned to the default profile upon their first SSO login. The default profile is usually the permission profile that has the least number of permissions enabled.
Update users
This option ensures that Bynder checks the user mapping upon every login and will update the user profile according to the latest profile sent in the SSO request. This way you can ensure that your users will always have the rights they need in the portal.
SSO Button, Intro Text and Alternative Login Text
The default intro text will be available on the login page of the portal. The intro text can be disabled or customized by us.
By default, the default text of the SSO login button is Use your COMPANY NAME credentials. If you prefer a custom label we can set up an alternative text. In case you don't want to offer SSO as a login method, we can hide the SSO button completely.
Users who can't login with SSO can use their credentials to log in. The default alternative login text can be customized. If necessary, we can completely hide the alternative login text as well as the the username and password fields.
SSO Focus Login
When SSO focus login is enabled the fields to enter your credentials will by default not be visible on the login page. Make use of this option if the majority of your users can login with SSO and when you prefer them using SSO instead of credentials. Users who can't access the portal using SSO can click a link, which will populate the fields to enter their credentials. The text of the alternative login link can be customized.
Bypass Bynder Login Page
Do you not want to show the Bynder login page and immediately redirect users to your organizational ADFS login page? We can set up specific IP addresses that should bypass the Bynder login page and redirect them to an alternative login page where users can log in using SSO. We can also disable the Bynder login page completely and redirect all users to the alternative login page.
Provide us with the exact names of the ADFS profiles and groups you would like to have mapped with Bynder permission profiles or groups. This way, the users will be automatically assigned to the mapped permission profile or user group upon SSO login.
-
Provide us with the user attributes you would like to have mapped to Bynder. This way the user profiles can be automatically pre-filled with user information from your Active Directory. This will save you, other administrators and users the time of having to manually enter this information. The following user attributes can be mapped:
Note
The user attributes need to be written exactly as indicated below and are case sensitive.
Bynder only accepts Name, not FriendlyName, as the naming convention for the attributes sent in the SAML request. For example, when sending emailaddress, please use the convention of Name="emailaddress" and not FriendlyName="emailaddress".
User Attributes
NameID
The NameID value is used to map the username. This field is required but if it's not an email address, Bynder will fall back to either the emailaddress or mail value.
emailaddress, mail
name, givenName
surname, sn
departmentNumber, department, employeeType
country
city
Company
JobDescription
Telephone
(Optional) If you don't want to make use of profile or group mapping provide us with the default permission profile that users should be assigned to upon their first SSO login.
-
Prepare and send information to Bynder so that we can enable the SSO for you:
-
Prepare a federationMetadata.xml metadata file. The federation metadata file can be exported as an XML file or can be sent as a URL. To find the XML metadata from the AD, type the following URL in a browser on the AD server:
https://adfs.yourdomain.com/FederationMetadata/2007-06/FederationMetadata.xmlNote
This is a generic URL that you can always use to get your metadata information. You only need to replace theyourdomain variable with the real domain name for which you want to get data.
You can refer to the attachment for an example of the file. You might need an app, such as TextWrangler to open the file.
Create an AD test account that Bynder can use.
-
Do you experience a technical issue with your SSO provider, such as ADFS, Okta or Azure? For any technical assistance we advise you to reach out to the technical support department of your SSO provider.
Bynder Support doesn't have access to your SSO provider and, therefore, can't further assist you with this type of enquiries.
Comments
0 comments
Article is closed for comments.