This document contains the settings used to configure Single Sign On (SSO). It should be used as a reference if the settings change accidentally (e.g. during a migration test run) or while troubleshooting any SSO issues. If you update any SSO settings, please edit this document.
The General Info section contains basic information about the Jive instance and the XML metadata files necessary to configure SSO. Attribute Mappings lists the mappings between Jive profile fields and data sent by the identity provider in the SAML response. These mappings are used to create new user accounts and sync profile information on login. The setting used to sync permission groups is called "Group Mapping Enabled" under the SSO Advanced settings.
SAML: Security Assertion Markup Language (SAML) is the protocol that we use for SSO authentication.
Service Provider (SP): Jive acts as the SSO service provider. When users attempt to log in using the Jive URL, Jive sends a SAML request to the identity provider. The SAML request checks to see whether the user is authorized to log in.
Identity Provider (IdP): The SAML identity provider manages information about users and determines whether they are authorized to log in. Once the IdP receives a SAML request, it sends a SAML response to Jive containing information about whether the user is authorized to log in. The SAML response often contains additional data about the user. This data can be used to update user profile fields and/or permission groups.
Metadata: An XML file (or URL connected to an XML file). This file contains information necessary for the SAML configuration, such as the URLs that the SP and IdP will use to communicate. Exchanging SP and IdP metadata is the first step in SAML configuration.
Federated: Users are marked as federated if they log in using SAML SSO. They may also be federated if their account, profile fields, or permission groups are updated by an external source (e.g. LDAP sync.)
|Link to production SP metadata|
|Link to production IdP metadata|
|Link to test SP metadata|
- Admin Console > System > Management > System Properties
|Property Name||Property Value|
Single Sign-On Settings
- Admin Console > People > Settings > Single Sign-On > SAML
User Attribute Mapping
|Profile Name||Attribute Name||Federated|
|External Identifier override w/assertion attribute||Subject NameID||unchecked|
|Username override w/assertion attribute||username||checked|
|Mobile Phone Number|
|Home Phone Number|
|Setting||Value||Default Setting||Reason Changed||Purpose of Setting|
|Debug Mode||unchecked (should not be checked if not actively troubleshooting)||unchecked||Enable to provide detailed logging for troubleshooting authentication problems. You need to enable this setting during setup and validation, but turn it off in production.|
|Username Identity||unchecked||unchecked||When Username Identity is enabled, existing users that have been marked as federated, which also have a matching username or email address, will be mapped to the External ID the first time they log in. You should select this checkbox if you use LDAP sync, CSV sync, or web services to auto-provision users, or if you already have existing users in the instance who will be using SAML from now on.|
|Merge Local Users||unchecked||unchecked||When Merge Local Users is enabled along with Username Identity, unfederated users who log in via SSO will be automatically federated. You should select this checkbox when enabling Username Identity if any of the users who should use SSO are unfederated.|
|Provision new user account on login||unchecked||checked||Client has User Sync process||Enable this setting to ensure that when a new user logs in, the user account is automatically created within Jive. This setting is enabled by default and should not be disabled unless you seeded the Jivecommunity with users before enabling SSO.|
|Enable disabled user account on login||unchecked||checked||Client has User Sync process||Enable this setting to reenable a disabled user's Jive account when s/he logs in.|
|Sync user profile on login||unchecked||checked||Client has User Sync process||Enable this setting to update users based on the remote user profile each time they log in.|
This option is enabled by default. It requires that to pass validation, theAuthnResponsemust have a valid signature on the Assertions within the Response. If the Response itself is signed, it also requires that the signature be valid. (It does not require that the Response be signed.) Clearing the check box enforces that the Response must be signed, and any signature on the Assertions is ignored. Most IdPs sign the Assertions section in the AuthnResponse. If you use SFDC, however, you should clear this check box, because SFDC only signs the entire Response.
|SSO Service Binding||urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST||urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST||Defines whether Jive should send the request to the IdP with an HTTP GET Redirect or a POST. The default service binding is urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST, which is the most commonly used binding. In order to use this binding, you must ensure that a Location binding with this value is in the IdP metadata. POST is typically preferred to Redirect, because older versions of Internet Explorer and some firewalls have restrictions on the length of the HTTP path. Note: If you're configuring ADFS, keep in mind that using POST can cause problems for users on Safari.|
is a page that doesn't require authentication. If guest access is disabled, users need to land on a non-authentication-requiring page. (Otherwise they'd be automatically logged in again.) If guest access is enabled, you can set this value to /index.jspa
to redirect the user back to the instance homepage, but as a guest user instead of as the account they were logging out of. Another option is to set it to the IdP logout URL, so that the user is logged out of bothJive and the IdP. We do not support theSAML SingleLogout (SLO) protocol. Changing this setting requires you to restart the Jive server.
|Max. authentication age||28800||28800||Identifies the maximum session time (in seconds) that's set for the IdP. The default setting is 28800 seconds, or 8 hours. However, to avoid login failures, you need to set this to match the maximum session set on the IdP. (Some IdPs are set to expire sessions less often.)|
|Response Skew||120||120||Specifies the maximum permitted time between the timestamps in the SAMLResponse and the clock on the Jive instance. The default value is 120 seconds. If there is a significant amount of clock drift between the IdP and Jive, you can increase this value. The same value is also used for the skew in the NotBefore check in the response. If you see an error indicating a problem with the NotBefore check and you aren't able to fix the clock difference problem, you can try increasing this value. However, increasing the response skew value can increase your security risk.|
|Setting||Value||Default Setting||Reason Changed||Purpose of Setting|
|Request Signed||Checked||unchecked||This setting determines whether theSAML request is signed or not. Enabling this setting can increase security, but it's incompatible with some IdPs. This setting is disabled by default.|
|Base metadata URL:||https://prudential-int-insurance-v8.hosted.jivesoftware.com/||This value sets the desired URL for the entityID and endpoint URLs. This URL should be an https. If you aren't using a URL with https, you need to get help from Support to continue setting up SSO. This setting typically matches the jiveurl system property.|
|Enable Username Confirmation for New Users||unchecked||unchecked||This setting will define the behavior for new users when they first log in. When enabled, users will be asked to confirm that they want to use the name and username that is provided by the Identity Provider. Users can change these values if they wish. If you select this check box, users can also modify these profile fields after initial login.|
|Enable Email Confirmation for New Users||unchecked||unchecked||This setting will define the behavior for new users when they first log in. When enabled, users will be asked to confirm that they want to use the name and email address that is provided by the Identity Provider. Users can change these values if they wish. If you select this check box, users can also modify these profile fields after initial login.|
|Allow Federated Users to Change Name||unchecked||unchecked||This setting will allow users to edit their first and last name on their profile. When the setting is disabled, the Identity Provider should set the first and last name, either as fields in the SAML response or through another synchronization method.|
|External Identity is Case-Sensitive||checked||checked||Use this setting to determine whether the value used for the external identity should be case-sensitive. You should disable this setting in a case where the external identity value changes under different circumstances, for example when it's sometimes all lowercase and sometimes all uppercase.|
|Force Authentication||unchecked||unchecked||Forces any user with an existing IdP session to log in again.|
|Passive Authentication||unchecked||unchecked||When guest access is enabled, issues a SAML AuthnRequest upon first access with "isPassive=true", which should cause the IdP to simply redirect back to Jive if the user doesn't have an active session with the IdP.|
|NameID Format||For most IdPs, using the default setting is correct.|
|NameID Allow Create||unchecked||unchecked||By default, this check box is cleared. You should leave it cleared unless you receive an error about NameID creation while setting up your SAMLintegration|
|Sign Metadata||unchecked||unchecked||Specifies that metadata should be signed. You should clear this check box UNLESS your IdP requires that the metadata be signed. If you use ADFS, you must clear this check box.|
|IDP Want Response Signed||unchecked||unchecked||Use this setting to add a configuration to the SP metadata that tells the IdP that the SAMLresponse should be signed, instead of only the assertions within the response. You should not enable this setting unless Support recommends it.|
|Requested AuthnContext||Along with Requested AuthnContext Comparison, this optional setting is used to add additional information to requests in certain specific cases. It's disabled by default.|
|Requested AuthnContext Comparison||Along with Requested AuthnContext, this optional setting is used to add additional information to requests in certain specific cases. It's disabled by default.|
|RSA Signature Algorithm URI||http://www.w3.org/2001/04/xmldsig-more#rsa-sha256||xmldsig-more namespace||Defines the algorithm used in the digital signatures used within theSAML messages. Most IdPs use the default value ofhttp://www.w3.org/2001/04/xmldsig-more#rsa-sha256. You may need to change this value if your IdP uses a different algorithm.|
|Group Mapping Enabled||unchecked||unchecked||You can assign users to security groups automatically by passing a special group attribute from the IdP to Jive. Select Group Mapping Enabled to enable this functionality and provide the group mapping attribute. The group mapping attribute will be used to get security group names from each assertion. If the corresponding groups with these names don't exist, they will be created when you synchronize, and users will be added to these groups.|
|Group Mapping Value, if Group Mapping Enabled is checked||See above|
|Require Valid Metadata||unchecked||unchecked|
Use this setting to determine whether the IdP metadata you provide to Jive should be validated with respect to any validUntil timestamps. Some IdPs generate metadata with arbitrary validUntil
timestamps on their metadata, which can cause validation to fail and keep Jive from running. This option is disabled by default.
|Include Scoping||unchecked||unchecked||This check box is unselected by default. If you use ADFS, it must remain unselected. Some IdPs may require a scoping definition|
|Proxy Count||2||2||This setting specifies the maximum number of proxies any request can go through in the request to the IdP. The default value is 2. If your IdP needs more than 2 proxy redirects, adjust this value upward.|
|Validate InResponseTo||checked||checked||If the InResponseTo field exists in the SAML response, this setting will validate that it is set correctly. This setting should only be unchecked if there is a reason that the InResponseTo field would not correspond with the SAML request.|
User Attribute Mapping