Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...


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.
Issue: 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.
Define standard so that we avoid, “But this is my standard.”

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?
If the eduPerson schema won’t fly in SAML2int, we will add this to the deployment.

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.


...