Membership Sets¶

MembershipSet is a concept introduced to Sequel Security to model templates of memberships that can be applied automatically to users as part of integration on cross-domain identity scenarios. A membershipset is composed of pairs of a role and a group. This set contains an unique identifier and a friendly name; and can be linked to a group on any identity provider (aka data source) supported in order to translate the role-level access from the IdP to Sequel Security service.

Membership management¶

MembershipSet can be configured from the Security API and from Administration UI at the Membership Set section.

Membershipset configuration¶

The membershipset is defined by an identifier or key that must be unique in the system, a name and optionally matching conditions for linking this membership with an IdP group, it can be done defining:

• Azure AD: id and displayname.
• LDAP: DN (Distinguished Name) or CN (common name).

The logic about matching is described below in the next sections.

For each membership set, we can define the associated memberships. This information will drive the transformation logic applied to assign memberships to user; this is covered in "Transform: Membership > Transformation Logic".

When a row defines both values, this will generate the same entry in the user.

When a row just define group or roles, means that all combinations of those values, in the same application, (in all entries of affected membership sets) will be generated (cross join).

Both samples in screenshots will produce the same results (if no other membershipset are involved).

Translation logic¶

The mapping for memberships is more complex, as we have to transform a single value (IdP group) in a pair of role and group. For being able to map a IdP group to a Membership set, the matching fields should be configured depending on the type of integration used:

Matching fields¶

Azure AD¶

• if both are empty this membership set will never be used for syncing,
• if Id is populated, the matching will be done using this field.
• if DisplayName is populated, the matching will be done using this field.
• if both are populated, both are used. So if matching with Id fails, the DisplayName is attempted.

Multiple membership set can be configured for matching with the same Id or DisplayName.

LDAP¶

• if both are empty this membership set will never be used for syncing,
• if DN is populated, the matching will be done using this field.
• if CN is populated, the matching will be done using this field.
• if both are populated, both are used. So if matching with DN fails, the CN is attempted.

Those properties refers to a AD Group expressing DN or CN (keep in mind DN is more accurate -referring to a single object- and CN not).

• LdapMatchByDN: We will expect to follow a valid DN syntax. Sample: CN=Claims,DC=sequel,DC=com
• LdapMatchByCN: We will expect just the CN value. Sample: Claims

Multiple membership set can be configured for matching with the same DN or CN

Define translations¶

On most IdP a group can be used for different purposes; related to our problem, a group can model:

Access control and permissions defined in the same groups¶

A single group at the IdP defines ACLs (groups) and permissions (groups). Those IdP's groups could look like: Underwriters_Marine, Underwriters_Aviation, Claims_Marine, Claims_Aviation; and they could be translated to Sequel's roles/groups model as:

Defining this scenario, is straight forward using the Membeship sets; as we just need to define the role+group pairs. When this membership set matches with an IdP group; the memberships fully defined are directly applied to the user. A

Access control and permissions defined in different groups¶

A group at the IdP defines the ACLs (groups) or the permissions (groups); but not both at the same time.

• Access control (group): the IdP group defines the ACLs, we can see as the team or business unit. The role/permissions about what you can do with this information is not defined here.

  IdP group	Sequel Role	Sequel Group
  Marine	??	VSBS.Marine
  Aviation	??	VSBS.Aviation

• Permissions: the IdP group defines the role of the users; the actions they are allowed to perform. However, the access to the information is not defined at this group.

  IdP group	Sequel Role	Sequel Group
  Underwriters	VSBS.Underwriters	??
  Claims	VSBS.Claims	??

With these IdP groups where role or group cannot be inferred directly; the translation mechanism provided by membership set allows to use the operator *. This operator defines a cross join with all other roles/groups defined using this operator. Let's review below definition:

This could generate for an user below memberships (pairs of role+group):

Summary¶

The logic for translating IdP groups to memberships sets can be described then as:

Sample¶

Let's assume below mapping configuration for translating groups to Sequel's memberships:

For simplicity, we are defining just a membership on each membership set but it is possible to define many.

In this scenario, we will have below mappings for some users: