Setting up an SSO client

1. Click Add Client.
   

1. Type a client name (used as entity ID). Make sure you follow the indicated type and number of characters. This client name will be used to determine the unique entry point for your organization's users and therefore must be globally unique in our system.
   

1. Select how you want to assign roles to your users by doing one of the following:
   
   
   • To assign a default role to users trusted by you, select a Media portal role from the Default Role list. For all new users trusted by your IDP, Media portal will create an account for them and assign the default role you selected. (We recommend assigning the Reporting role because it has the lowest permission level.)
     
     If we encounter a user trusted by you but without a way to determine the intended role, we will automatically defer to the default role. If done without role mapping, setting a default role indicates that for every new user trusted by your IDP, we will automatically create an account for them with the role you have set as the default. This function can be used alone or in conjunction with role mapping.
     
     
   • To map your internal SSO group roles to Media portal roles, select the Role Mapping checkbox, then do the following to map your role names to Media portal roles:
     
     
     1. In the SP Attribute Name field, type your SAML attribute name, where the roles will be provided in the payload of the SAML2 authentication exchange. (This name is case sensitive.)
        
        
     2. For each of your organization's native role names, map them to Media portal roles: select the Media portal role from the list and type your role name in the SSO Group Name field. (The role name is case sensitive. Click Add to add additional rows to hold each role.)
        
        
     3. If you want Media portal to use a default role for roles you haven't mapped, select a Media portal role from the Default Role list. (If you don't have a default role in conjunction with mapped roles, Media portal will deny access to any user that does not have a known or mapped role. Use this option if you do not want everyone in your company to have access to the Media portal. If a user was already set up in Media portal, the IDP will still determine the role and the user's record will be updated accordingly directly following authentication.
        

1. Paste or upload your IDP metadata obtained from your IDP.
   

1. From the SP Initiated Message Type field, choose the request method that the Media portal (SAML SP - service provider) should use. (Certain IDPs require POST; others require GET.)
   

1. Click Create.
   
   Media portal (SP) shows the metadata you need to register with your IDP.
   

1. When ready, enable your client. Your client will be in an Inactive status when you create it and you can enable it at your convenience. Once enabled, it will be functioning nearly immediately and the same timing applies should you decide to disable it.
   

Users should use the URL that is specific to your organization: https://mediaportal.lumen.com/sso/saml2/sp/init/{SSO client name}. If users go to https:/mediaportal.lumen.com, they will be redirected to an intermediary page that provides your organization’s URL. The user can click Sign In to proceed. To save clicks, we recommend bookmarking your organization-specific SSO URL.

SSO user profiles in the Media portal are greatly simplified and only show what is provided by the SAML2 assertions passed in the authentication exchange. The SSO user name is always present and, if provided, the first and last name are also shown. Additionally, there will be no options manage a user's password or status because this is now controlled by your IDP.

The SSO client must provide the SAML2:NameID (user name expressed as an email address). Optionally, the following can be provided:
 

• “firstName” and “lastName”—if not provided, dashes will appear in the Media portal user profile.
   

• role, where the attribute name corresponds to the values provided in the role-mapping screen—if not provided, as described previously, the login request will either cause the default role to be assigned or the login request rejected (depending on how you configure the SSO client).

<saml2:Assertion ID="_1184305154138349862" IssueInstant="2021-08-31T15:16:06.093Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
saml2:Issuer<https://localhost:10443/sso/idp</saml2:Issuer>>
saml2:Subject
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">john.smith@mydomain.com</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData InResponseTo="_d8c523d1b65eef00c636a91ddfcf5935" NotOnOrAfter="2021-08-31T15:17:46.065Z" Recipient="https://localhost:8443/sso/saml2/sp/callback/cas-localhost"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2021-08-31T15:16:06.122Z" NotOnOrAfter="2021-08-31T15:17:46.122Z">
saml2:AudienceRestriction
saml2:Audiencecas-localhost</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2021-08-31T15:16:06.065Z" SessionIndex="_4837487843227240903">
<saml2:SubjectLocality Address="cas-localhost"/>
saml2:AuthnContext
saml2:AuthnContextClassRefurn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
saml2:AttributeStatement
<saml2:Attribute FriendlyName="samlAuthenticationStatementAuthMethod" Name="samlAuthenticationStatementAuthMethod">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">urn:oasis:names:tc:SAML:1.0:am:password</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="lastName" Name="lastName">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">Smith</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="firstName" Name="firstName">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">John</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="role" Name="role">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">Admin</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="isFromNewLogin" Name="isFromNewLogin">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">true</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="authenticationDate" Name="authenticationDate">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">2021-08-31T09:16:05.868-06:00[America/Denver]</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="authenticationMethod" Name="authenticationMethod">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">AcceptUsersAuthenticationHandler</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="successfulAuthenticationHandlers" Name="successfulAuthenticationHandlers">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">AcceptUsersAuthenticationHandler</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute FriendlyName="longTermAuthenticationRequestTokenUsed" Name="longTermAuthenticationRequestTokenUsed">
<saml2:AttributeValue xmlns:xsd="http://www.w3.org/2001/XMLSchema%22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance%22 xsi:type="xsd:string">false</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>