Federation Frequently Asked Questions

Table of Contents

What is federation?

Federation is simply a means of creating a trust between a Service Provider (SP) and an Identity Provider (IdP) which facilitates user authentication to the service being offered. This allows you to sign into Bentley with your work/domain credentials, while securely performing that authentication at your organizations IdP. This is commonly otherwise known as Single-Sign On (SSO).

How long does it take to federate with Bentley?

That depends on you - we can do it very quickly, or take as much time as you like to get it approved, configured and tested with multiple user groups. You are under no pressure either way.

For proper SLA guidelines on new federation requests, please refer to this link: New Federation Request - SLA - User Management and Identity Wiki - User Management and Identity - Bentley Communities

Can I turn on IMS federation in the midst of another migration? 

Federation with Bentley IMS is an independent project and can be completed at your own pace without regard for any other work you're doing with Bentley. There are no dependencies on federation and applications are not impacted by your decision to federate with Bentley IMS. You may complete federation before, during, or after any other on-going work.

Interested in setting up federation with Bentley?

Submit a request for federation here and a federation engineer will assist you.

What's an Identity Provider (IdP)?

An identity provider is a term used to describe a service which allows for user authentication which then returns details about the user that authenticated to the requesting Service Provider. The primary details we gather from your Identity Provider are: First name, Last name, Country, and E-Mail/UPN. Depending on your Identity Provider, additional details (ways to validate the transaction, other minor details about the user or organization) will be returned in the security token sent to Bentley; however, these details are discarded after the primary details are pulled from the security token and the necessary validation is done. Common examples of an IdP include Azure AD, Ping ID, Okta, ADFS, and many others. 

What's a Service Provider (SP)?

A service provider is exactly that - a service (application) being provided to you and in context of federation, relies on an Identity Provider to give details about the authenticating user to the Service Provider as the Service Provider itself is not handling authentication in the service. 

Does Bentley support IdP-initiated SSO?

Bentley only supports SP-initiated federation at this time. This means that federation is triggered by going to the CONNECTION Client or any SaaS application which utilizes Bentley Identity Management System (IMS) Authentication, identified by this login screen below and providing a federated domain. If the domain is federated, you will be redirected back to the Identity Provider for the specified domain. If the domain is not federated, you will be prompted for a Bentley IMS password. Federated domains are coordinated during federation set up. 

Can I federate a domain in use by multiple organizations at Bentley?

No. There are technical limitations which require that all users from a single federation be linked only to a single Bentley organization, or in other words, all users must be a part of the same User Management in order to federate. There is no way to split the users into multiple organizations.

Can I test the federation prior to activation?

Yes. We will set up the federation in production, in a special isolated mode which allows for users with special testing instructions to test the federation. You will be signed into your real, production IMS account. You should maintain the same access to across all applications. If you have any issues during testing, please be sure to let the engineer that is working with you for your federation know of the issues. 

Are there any impacts when I activate the test federation?

No. When the test federation is activated, even if you're migrating from an old active federation, users will not be interrupted. Users do not need to sign out and sign back in for any reason.

Do I still need to create user accounts after I activate federation?

No. Federation will automatically create a user account if it does not exist and the user will automatically show up in your user management with immediate access to your default entitlements.

What are the differences between ProjectWise/CONNECTION Client federation and IMS/Identity Provider federation?

The connection between ProjectWise and CONNECTION Client simply allows for you to sign into your IMS-enabled ProjectWise Datasource with the same IMS account that you've already signed into the CONNECTION Client with. However, ProjectWise does not know what type of authentication you performed to access the CONNECTION Client - whether federated or native authentication with Bentley username and password. It simply reuses the session from the CONNECTION Client to sign you in.

The connection between IMS and your IdP allows for you to sign into the CONNECTION Client with your work/domain credentials. This signs you into your IMS account which is then passed into the Service Provider, such as CONNECTION Client. CONNECTION Client then acts as an Identity Provider to applications like ProjectWise and shares the details of the authenticated user to get them signed into the applications downstream from CONNECTION Client. 

Here's are a couple images to illustrate the flow:

Are the sessions between the CONNECTION Client and SaaS applications shared? 

No. As a security measure, the CONNECTION Client and your SaaS applications do not share sessions. This means you will need to sign into the CONNECTION Client and your SaaS application separately and they will maintain different sessions. 

How long are my sessions good for? 

Sessions inside of the CONNECTION Client are good for seven days and on the sixth day, the CONNECTION Client will automatically reach out to IMS to refresh the users token. IMS will reach out to your Identity Provider and confirm if the user is still an active and authorized user and after doing so, issue a new token to the CONNECTION Client, keeping the user signed in. If this fails for any reason - no internet, your machine was off, the user was blocked, etc., then the user will be signed out of the CONNECTION Client after the token expires on the seventh day and they will have to sign back in. 

Sessions inside of web browsers are good for 24 hours of continuous activity. If there is one hour of inactivity, the session will be expired. Do note that sessions are maintained in the browser storage and if any tab expires the IMS session, then all tabs utilizing an IMS session will be expired for that browser, even if that tab is another window for that browser. Each browser maintains its own storage, so a session expiring in Edge would not expire a session in Chrome. 

How do I change my E-Mail/Username?

Federated users are not permitted to change their E-Mail/Username. If you need to change your E-Mail/Username, please let one of your account admins know and they can assist you with changing your E-Mail/Username.

Account Admins can update the users E-Mail & Username at the same time by utilizing the Bulk Operation tool from https://usermanagement.bentley.com/ using the following instructions.

IMPORTANT NOTE: Federated users are being identified by a unique value being provided to us after the user authenticates at your identity provider. If you change the users IMS E-Mail/Username to a value that does not match up with the identifier from the federation, then the user will end up getting signed into a second account. The identifier and the IMS E-Mail/Username must match in order for the user to get signed into the correct account. If you would like some assistance with making changes to your federated users E-Mail/Username, please submit a ticket and a federation engineer will assist you with the changes. 

How do I change my password?

Federated users passwords are not managed by Bentley, nor are they ever shared with Bentley. Since you are signing into your work account, you will need to reach out to your work's IT team to reset your password. 

Can I control what users sign in through federation?

Yes. Your Identity Provider will give you some way to enforce a list of users or groups which are allowed to sign in through the federation application. Once you are federated, your identity provider is responsible for confirming who should or should not access the application, and we trust your identity provider to only provide security tokens for users which should be accessing Bentley. 

Can I utilize Azure B2B or B2C authentication or some other form of external authentication? 

Yes. Please submit a ticket for federation support to set this up.

Will this effect my other users which access my collaborative resources? 

Only users which login with the specified federated domains would be effected. If the users in question share the federated domain, then yes, users will be forced to perform federated authentication. If their domain does not match the federated domain, then the user will remain unimpacted by any changes we are working on.

I'm migrating my federations from one connection to another, what do I need to know?

Migrating connections is a seamless experience which allows for you to move from one federated connection, such as an Azure AD WS-Fed based connection, to a new connection, such as an Azure AD OIDC connection. Migration can also support moving from one IdP to another, for example, moving from Azure AD to Okta. 

Migrations are handled the same way as setting up a new federation. We'll create the new connection in a test setting where you'll be able to confirm that the connection still signs you and your colleagues in without issue. Then after you're satisfied with the connection you can confirm with your assigned engineer and they'll help activate the federation for all users. 

Migrations should not introduce any change in user experience. A federation engineer will review the update with you and should there be any changes, they will be discussed with you prior to implementing any changes. 

Please remember to carry forward or introduce any necessary authorization controls for the new federation in your IdP.

What is a client secret?

client secret refers to a confidential piece of information used to authenticate an application in an identity provider (IdP). IMS uses the client secret that has been provided to prove its identity when communicating with your IdP. If this secret expires, then IMS can no longer prove its identity with your IdP and the authentication for the user at IMS would be rejected because IMS can't finish the authentication user. You are responsible for tracking the expiration and replacement of the client secret for your connection. The lifetime of a client secret is variable and should be set in accordance with your organizations security policies.

What is a secret token?

secret token is issued by Bentley, and it's required when Azure AD user provisioning is set up. The main purpose is similar to that of a client secret, authorizing your Azure AD to make changes in User Management on the administrator's behalf. User provisioning secret tokens are valid for 12 months only and administrator will get notified 15 days before the secret token expiration date. To request a new secret token, please contact IMSTeam@Bentley.com.