Beanlogin recommends using an agent-less approach as it is built on the concept of claims-based authentication model, in which the applications will no longer build the logic to authenticate users, instead, they will trust an Identity Provider (IdP) that will issue a security token. These security tokens are digitally signed XML documents containing user data. The user data is nothing but user attributes, also referred to as claims.
The applications that consume this security token are called Relying Party applications or claims-aware applications or a Service Provider (SP).
Already Federation Enabled?
BeanLogin supports WS-Federation and SAML protocols today. If your application is already claims-aware or Federation compliant, then all you have to do is setup Federation. Please refer to the Federation Setup Guide.
Further, we have pre-defined templates for popular cloud apps like Office 365, SharePoint, Slack, Google Suite, Salesforce, Confluence etc. The Federation setup guide has detailed documentation with the steps to be followed for the integration.
Not Federation Enabled?
Don’t worry. We’ve got you covered as well. Please refer to the Developers Guide and download our handy developer toolkit to enable SSO with BeanLogin.
Articles
- Federation Setup Guide
- BeanLogin Integration with Confluence
- BeanLogin Integration with Office 365
- BeanLogin Integration with Salesforce
- BeanLogin Integration with Slack
- BeanLogin Integration with AWS
- BeanLogin Integration with BambooHR
- BeanLogin Integration with Dropbox
- BeanLogin Integration with Jenkins
- BeanLogin Integration with Cloudbees Jenkins
- BeanLogin Integration with PeopleHR
- BeanLogin Integration with PurelyHR
- BeanLogin Integration with Cisco Umbrella
- BeanLogin Integration with Aha
- BeanLogin Integration with ZenDesk
- BeanLogin Integration with Azure AD
- BeanLogin Integration with Deskpro
- BeanLogin Integration with Domo
- BeanLogin Integration with Front