...
Issue(s) | Section | Description | Notes |
7, 8 | Applications that support provisioning of access control MUST allow this provisioning to take place via attribute value mapping for values supplied in the assertion. [SC - this would have to get more concrete if we wanted to require a behavior] [ME - Outside of SAML2int, give guidance to deployers who want to share access control information - example: REDCap] [KW - May be for a class of applications with fully externalized access control] | ||
39 | Deployers should support a non-targeted, non-opaque, persistent, non-reassigned scoped identifier for collaboration across research organizations. (Presume this was referring to IdPs) | ||
36 | Service providers must ensure that a request for forced reauthentication results in a valid current assertion. | ||
50 | 7 | Deployers should choose from standard LDAP/X.500 (inetOrgPerson?) and eduPerson attributes where possible and should avoid creating custom attributes that duplicate the function of a standard attribute. | |
34 | 5 | Deployers must include a security contact in published metadata | |
7, 8 | Applications that do on-the-fly provisioning: Should use an attribute value to trigger provisioning, and absence of that attribute value should cause deprovisioning | Text from github issue on our saml2int wor, prepared by JudithBush: While most of the discussion about HOW skewed towards an InCommon solution, it seems a brief normative directive addressing the issues below should be included in saml2int. KEY ISSUE: need an attribute that signals provisioning and ALSO deprovisioning an account. Or Don’t do online provisioning without an authorizing component. Does this imply using eduPerson entitlements instead of group membership? The current tone doesn’t seem to imply this, but we think it should. (But that’s a preference? And the community wants to go the other way? Or maybe this is rare in Federated exchanges? | |
NEW | As a deployment, your entityID MUST contain the domain of whatever organization is the owner of the application, in the case of an SP; or the owner of the organization whose users are represented by the IdP, in the case of an IdP. | ||
NEW | IdPs MUST/SHOULD publish a shibmd:scope in metadata, and asserted attributes MUST(barring something unusual) match the published scope, and SPs SHOULD verify/restrict scopes on asserted attributes to match that scope. | ||
NEW | Metadata MUST include UI elements for display name. SHOULD include logo, description and privacy policy. |
...