Table of Contents
- Will SSO provisioning override any user accounts – including role and department assignments – that were previously set up manually?
- Can user provisioning assign the product(s) that a user will have access to?
- For users created manually, when logging in with SSO dynamic user provisioning, will products be overwritten?
- What actual SAML field does “department” and “role” look at?
- How does the isMemberOf attribute work?
- Related Articles
Will SSO provisioning override any user accounts – including role and department assignments – that were previously set up manually?
Answer
Yes, for most schools SSO provisioning will override what you’ve created manually in-app, as these configurations will apply to all users.
If, for example, you have SSO provisioning set to assign a default role of “Event Requester” to everyone in Events, that would override the assigned role for users that were previously assigned the role of “Admin”.
Consequently, it's important to have the actual roles and departments for users being passed in the attributes to prevent overriding previously assigned roles.
Additional Note/Consideration
An exception to the above answer would be if your school is using the “Do not update user attributes” feature.
If your school is using this feature (which isn’t recommended for most schools), user attributes only update upon the user’s first login but will not update again on subsequent logins (in other words, user attributes will need to be managed in Coursedog).
Can user provisioning assign the product(s) that a user will have access to?
Not currently, but that’s something we’re exploring.
For now, you can assign default products.
For users created manually, when logging in with SSO dynamic user provisioning, will products be overwritten?
No. Manually assigned products, including the Admin panel, will not be overwritten.
What actual SAML field does “department” and “role” look at?
All info about departments and roles must come within the isMemberOf attribute – the name of the attribute is configurable in our Admin panel.
The User Provisioning configuration defines the attribute name.
How does the isMemberOf attribute work?
Overview
Everything that comes within that isMemberOf attribute will be matched against the Department Structure and Role structure configs.
Note we’re referring to the content within the tags, not the tags themselves, so customers must specify what's the structure of the role/department and where in the received string we will find the actual role.
For example:
If EMPLOYEE is the entire content of a tag, the config of the structure is simply <role>, because all of the content is a role.
If namespace:user:roles:EMPLOYEE is the content of a tag, the configuration should be namespace:user:roles:<role>, because the actual role is the last bit of the string.
The same applies to departments.
Additional Notes
Since departments and roles are defined as a part of the same multivalue isMemberOf attribute, the role structure defined simply as <role> will match every attribute sent inside the isMemberOf, because from our system’s perspective, we won't be able to distinguish between roles and departments even if the department structure would be prefixed, e.g. dep:<department> .
The roles and department wildcards (<role> and <department>) match ONLY alphanumeric and _ characters, so : , - , and others are considered stop-signs. That means that if we receive Coursedog-Admin and the configured role structure is <role>, then we will decode ONLY Coursedog (dropping the -Admin) part.