This document is meant to serve as a high level guide to authentication and user sync.
If the authentication method does not allow for deprovisioning users (most do not), customers may set the number of months that should pass with no login activity before a user account is automatically disabled. See user.decay.period in Undocumented Jive System Properties | Jive Community
|Method||Explanation||User Provisioning?||Pros||Cons||Cloud Considerations||Hosted Considerations|
|Jive native authentication|
Jive manages user identity
User username and password are stored in Jive application database
Allow users to create own accounts or admin manually adds.
Deprovisioning is manual.
Most common for external communities
|Requires manual admin management for new and departing users||Internal: username must be email address|
User identity is managed in corporate Active Directory server (LDAP Servers are separate from an IDP & often work in conjunction with the IDP. 90+ % of LDAP servers are AD but not all) .
User enters username/password on login page. Jive connects to customer AD Server to authenticate credentials.
Note that users who sign into an AD Server need to enter their credentials on every sign in, and sign in separately from any other desktop application (i.e. this is not Single Sign On).
|Provision and deprovision (option) is automatic at time of user login|
Many corporations manage identity through Active Directory
|VPN is often required to connect to corporate AD Server, and can take a long time to set up.||Customer must provide access through firewall from Jive Cloud instance to AD Server. Can whitelist Jive IP address.||Many customers choose VPN for Hosted to AD Server (LDAP server) communication|
User identity is managed in SAML-compliant IDP (Identity Provider)
User logs in directly to IDP. If user has already logged in, authentication to Jive is transparent. If user hasn't logged into IDP, Jive login page will redirect to IDP login page.
Provision at time of user login
User identity is managed in corporate Active Directory server (LDAP Server). Okta agent is installed.
|Provision and deprovision (option) is automatic at time of user login||No VPN or direct connection to AD Server needed from Jive||Requires agent install on network||Cloud-friendly|
|Custom||Custom authentication is used mainly when a customer's IDP is not SAML, or their corporate authentication method uses multiple sources of identity for different user populations.||As defined||Possible only if implemented through APIs|
The authentication methods listed above outline the different ways to authenticate users to Jive, and provides some options for synchronizing user information at the time of user login. A user sync tool is generally used to provide additional capabilities:
- To deprovision users in Jive as soon as the user loses permissions in the corporate system of record (vs. deprovision at the time of the next user login, which may be never)
- Provision large population of users prior to launch, independent of whether the user has logged into Jive
- Populate user information not possible in the authentication method: org chart info, profile photos, etc
Customers may use one method for authentication and a different method for user sync: SAML SSO for authentication and LDAP nightly sync are often used together, for example.
|Method||Explanation||Data synched||Pull vs. Push|
Can provision and deprovision users only at time of login
|LDAP nightly sync|
Commonly used in internal communities to provision all users in advance of launch
Users are (optionally) deprovisioned nightly when sync runs
Does not re-enable users who have been disabled, though users are re-enabled on successful login
Okta agent is deployed on customer's network
Profile fields as follows:
Custom user sync can be implemented as an add-on in Cloud (? also for Hosted?)
|Defined by customization||Push|
Terminology and Related Info
- Federated = identity is managed by an external system