Difference between revisions of "SSO Check List"

From IVS Wiki
Jump to: navigation, search
Line 1: Line 1:
 +
__TOC__
 
{{Article | content = {{Checklist | list =  
 
{{Article | content = {{Checklist | list =  
==Where to Begin?==
+
=Where to Begin?=
 
Before SSO is configured on your VALT server, there are a few things that need to be done, setup, and understood. This article aims to help you identify where you are in the process and what steps might need to be done before you configure SSO on your server!
 
Before SSO is configured on your VALT server, there are a few things that need to be done, setup, and understood. This article aims to help you identify where you are in the process and what steps might need to be done before you configure SSO on your server!
  
Line 14: Line 15:
 
*{{Checkbox - empty | item = Server racked and patched}}
 
*{{Checkbox - empty | item = Server racked and patched}}
 
*{{Checkbox - empty | item = SSL certificate and NTP server installed}}
 
*{{Checkbox - empty | item = SSL certificate and NTP server installed}}
}} }}
+
}}  
 +
 
 +
<hr>
 +
 
 +
{{Aside | content = VALT is compatible with SAML 2.0}}
 +
{{Aside | content = To access SSO on your system, you may need to reach out to our support team. [https://ivs.help IVS Support]}}
 +
*Browse to the the Fully qualified domain name and sign in with a local account
 +
*Click on admin
 +
*Click on Users & Groups
 +
*Along the top click on SSO and add SAML config
 +
 
 +
<hr>
 +
 
 +
==To configure SSO VALT needs the following information:==
 +
*Certificate in .cer format
 +
*Identity Provider (IDP)
 +
*Remote Sign-In URL
 +
*Remote Sign-Out URL
 +
*Display Name Attribute
 +
*Any other custom attributes needed
 +
[[File:SsoConfigInformation.png|link=]]
 +
 
 +
After SSO is configured browse to <code>https://<b><Server Address></b>/saml/metadata.xml</code> to grab the VALT metadata to add to your system
 +
 
 +
<hr>
 +
 
 +
==User Mapping==
 +
<div class="floating_card">User mapping is used to map groups in the customer's system to groups within VALT</div>
 +
{{Aside | content = <b>NOTE:</b> SSO in VALT is a one to one mapping for groups}}
 +
 
 +
===Required===
 +
Users are mapped to VALT groups using attributes and values being passed from the IdP.
 +
<dl>
 +
<dt>Name</dt>
 +
<dd>The value to define the mapping. <em>Used only in this section of VALT.</em>
 +
<dt>Attribute</dt>
 +
<dd>The item that gets passed back to VALT.</dd>
 +
<dt>User Value<dt>
 +
<dd>The value of the item that gets passed back to VALT.</dd>
 +
<dt>Group to Add</dt>
 +
<dd>The group created on the VALT side that defines the user's rights in the application.</dd>
 +
</dl>
 +
[[File:SAML_UserMapping.png|link=]]
 +
 
 +
<hr>
 +
 
 +
==Other Notes==
 +
<h2>Moving from LDAP to SSO</h2>
 +
*If moving from LDAP to SSO you have to add a custom attribute to map to the username so the usernames will match correctly
 +
*To migrate current users to SSO the SQL command needs to be run on the database with the correct group ID
 +
UPDATE users set ldap_sync_id = NULL, saml_config_id = 1, userType = 'local'  where deleted_at is null and group_id =
 +
 
 +
<hr>
 +
 
 +
<h2>Custom Attributes</h2>
 +
*Custom Attributes can be usernames if you want to map to something specific or other information that you want to pull into VALT
 +
 
 +
<hr>
 +
 
 +
<h2>Additional Settings</h2>
 +
*Shibboleth IDP's need the following settings specified:
 +
<dl>
 +
<dt>signAssertions:</dt>
 +
  <dd>true</dd>
 +
<dt>signResponses:<dt>
 +
  <dd>true</dd>
 +
<dt>encryptNameIDs:</dt>
 +
  <dd>true</dd>
 +
<dt>encryptAssertions:</dt>
 +
  <dd>false</dd>
 +
</dl>
 +
}}

Revision as of 15:48, 6 October 2023

Where to Begin?

Before SSO is configured on your VALT server, there are a few things that need to be done, setup, and understood. This article aims to help you identify where you are in the process and what steps might need to be done before you configure SSO on your server!

The following list of items should be done, in order. Identifying where you are in this process is your first step.


☑ SSO Checklist

  • ☐ Recognize need/want for SSO

  • ☐ SAML discovery call

    • ☐ Understanding of VALT group mappings

    • ☐ Understanding of user creation and management

  • ☐ Server racked and patched

  • ☐ SSL certificate and NTP server installed


VALT is compatible with SAML 2.0

To access SSO on your system, you may need to reach out to our support team. IVS Support

  • Browse to the the Fully qualified domain name and sign in with a local account
  • Click on admin
  • Click on Users & Groups
  • Along the top click on SSO and add SAML config

To configure SSO VALT needs the following information:

  • Certificate in .cer format
  • Identity Provider (IDP)
  • Remote Sign-In URL
  • Remote Sign-Out URL
  • Display Name Attribute
  • Any other custom attributes needed

SsoConfigInformation.png

After SSO is configured browse to https://<Server Address>/saml/metadata.xml to grab the VALT metadata to add to your system


User Mapping

User mapping is used to map groups in the customer's system to groups within VALT

NOTE: SSO in VALT is a one to one mapping for groups

Required

Users are mapped to VALT groups using attributes and values being passed from the IdP.

Name
The value to define the mapping. Used only in this section of VALT.
Attribute
The item that gets passed back to VALT.
User Value
The value of the item that gets passed back to VALT.
Group to Add
The group created on the VALT side that defines the user's rights in the application.

SAML UserMapping.png


Other Notes

Moving from LDAP to SSO

  • If moving from LDAP to SSO you have to add a custom attribute to map to the username so the usernames will match correctly
  • To migrate current users to SSO the SQL command needs to be run on the database with the correct group ID
UPDATE users set ldap_sync_id = NULL, saml_config_id = 1, userType = 'local'  where deleted_at is null and group_id =

Custom Attributes

  • Custom Attributes can be usernames if you want to map to something specific or other information that you want to pull into VALT

Additional Settings

  • Shibboleth IDP's need the following settings specified:
signAssertions:
true
signResponses:
true
encryptNameIDs:
true
encryptAssertions:
false