As an Instance Administrator, I want to configure the SAML adapter to create users that are not in the user database using info from SAML assertion

• Type: Story
• Status: Closed
• Priority: Major
• Resolution: Completed
• Affects Version/s: None
• Fix Version/s: 7.4.13 DXP GA1, 7.4.3.4 CE GA4, Master
• Component/s: Application Security > SAML
• Labels:
  • 7.4-dxp
  • 7.4-must
  • fc_21_01
  • fc_21_02
  • fc_21_03
  • fc_21_04
  • fc_21_05
  • fc_21_06
  • fc_21_07
  • fc_21_08
  • has_acceptance_criteria
• Epic Link: SAML enhancements
• Sprint: AppSec Iteration 54, AppSec Iteration 55, AppSec Iteration 56, AppSec Iteration 57, AppSec Iteration 58, AppSec Iteration 59, AppSec Iteration 60, AppSec Iteration 61, AppSec Iteration 62, AppSec Iteration 63, AppSec Iteration 64, AppSec Iteration 65, AppSec Iteration 66, AppSec Iteration 67, AppSec Iteration 68

Description

The Attribute Mapping field of the SAML provider settings can have arbitrary entries in the mapping with verifications on portal side attributes. The values of the given SAML provider asserts will be saved to the appropriate portal User attribute values when the user signs in. There will be a separated field for the User attributes like it is working in LDAP configuration already.

The followings can be a later consideration:

1. To create custom fields for the the basic fields, that can be managed in the Attribute Mapping field already.
2. To have some notification to Instance Administrator if there is an exception at creating the portal User. For example in case of invalid values for any of the fields.

Acceptance Criteria

Same as the AC of LPS-105169.

1. As an Instance Administrator, I want to set portal User attribute from a predefined list to SAML assert mapping at the SAML provider settings according to which the assertion values are saved as portal User attribute values.
2. As an Instance Administrator, I want to have a verification at saving the SAML provider settings which checks the portal User attributes if they are existing portal User attributes. (Note: in the current implementation there is no way to send a non-existing attribute as the attributes can be chosen from a predefined list. However, it may be possible to do that in a hacky way so we may need the protection on server side.)
3. As an Instance Administrator, I want to have a verification at saving the SAML provider settings which checks for duplicated portal User attributes in the mapping.
4. As an End User, I want my data in IdP synced to my portal user when I sign in.
5. As an Instance Administrator, I want to be able to have the previous way of working as default working after an upgrade.
6. As an Instance Administrator, I want to be able to continue using the previous way of working after an upgrade.