Versions Compared

Key

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

...

 
#IssueIssue restated as requirementLimitationRelevant Profile SectionsResolved
1Manual exchange of metadata or (worse) raw config intoAutomated, ongoing metadata exchange and validationSoftware/OperationalIIP-MD04, IIP-ME04Yes
2Security risk/change control risk inherent in one-time MD exchangeAutomated, ongoing metadata exchange and validationOperational

IIP-ME03, IIP-ME04

Yes
3Lack of precise documentation and sloppy use of SAML constructs (in custom deployments)More specificity for use of some specific SAML featuresSoftwareThroughoutYes
4SP-initiated SSO as a "special" caseSupport for SP-initiated SSOSoftwareIIP-SSO01Yes
5Lack of deep link supportSupport for deep linkingSoftware/OperationalNot addressedIIP-SP13Yes
6Use of frames that break with 3rd party cookiesKeeping authentication screens as top level windows (not iframes)OperationalNot addressed 
7Lack of dynamic provisioning/entitlement-like attribute based authZSupport for attributes indicating group membership/entitlements (when customers handle authZ)Software/OperationalNot addressed 
8Lack of focus on AuthZ space and supportAs above?OperationalNot addressed 
9Lack of clock skew allowanceSupport for clock skewSoftwareIIP-G01, also recommend adding recommendation for consumption of time server service in a deployment profileYes
10Lack of encryption supportSupport for XML encryption at the SPSoftware

IIP-SP13, IIP-SSO04, IIP-MD09, IIP-SP02,IIP-MD10, IIP-MD11, Section 2.5 (IIP-ALG01 - 06), IIP-IDP11, IIP-IDP19

Yes

11Lack of key rollover supportSupport for key rolloverSoftwareSection 2.1.3 (IIP-MD07, IIP-MD08, IIP-SP13, IIP-IDP19)Yes
12Requiring valid (vendor signed and/or expiring) certsSupport for long-lived, self-signed certs, which may or may not be expiredSoftware/OperationalIIP-MD05, IIP-MD03, IIP-MD11Yes
13Lack of discovery support/portable links (w/o hard coded IdP refs)Support for discovery servicesSoftwareIIP-SP09Yes
14Hard coded 1:1 SP:IdP modelsSupport for multiple IdPsSoftware/OperationalNot addressed 
15Require non-opaque, non-transient NameID (rather than attribute)Support for account identifiers in attributes (rather than NameIDs)Software/OperationalIIP-SP03, IIP-SP08, IIP-IDP12, IIP-SSO05Partial; SP requirements simply state "don't misuse persistent" and "don't require nameid policy in AuthRequests". IdP says "don't require NameID in assertion". Do we need statement about SP accepting assertions not containing NameIDs?
16Requiring literal account IDs be asserted by IdPSupport for identifier mapping (i.e., IdP ID is mapped to an internal account ID)OperationalIIP-SP03Best Effort: Whether an SP actually supports this is a configuration issue, agreed that the profile allows for the desired configuration, even if a deployment forgoes leveraging the configuration capability.
17AuthnContextClass: not specifying at SP, but failing if PPT not used by IdPSpecify ACC; if unspecified, accept any ACCSoftwareIIP-IDP10Partial; Addresses the requirement in a roundabout way. Does not state "must not require an ACC if it is not specified in metadata". (Not clear that such a requirement would belong in this document, though).
18AuthnContextClass: can't handle locally defined AuthnContextClassesAllow support of extended ACC's (as part of site-specific configuration)Software
Possibly; arguably inferable from IIP-IDP10, but it is not clear from IDP10 that IdP must support arbitrary values for ACC.
19AuthnContextClass: no "step-up" supportSupport use of "step-up" authentication (re-auth with new ACC and poss ForceAuthnSoftware/OperationNot addressed 
20Assuming Logout URL existsVerify advertised IdP SLO endpoint before directing user thereSoftwareSection 4.5 (IIP-IDP17-20)Partial; Says IdP must support SLO, but does not indicate that SPs must honor IdP metadata. Do we need an SP requirement here?
21Logoff handling???SAMLSection 4.5 (IIP-IDP17-20)Probably
22Expectations of SLO???OperationalSection 4.5 (IIP-IDP17-20)Partial; (assuming this is largely a duplicate of issue 20)
23Browser cookie behavior impacting functionality (sessions not clearing, etc)???SAMLNot addressed 
24Attribute release standards for IdPs???OperationalNot addressed 
25Attribute release: suppressing grad students (FERPA concerns)???OperationalNot addressedIs this and 24 about configuring conditional release of data from specfiic users?
26Privacy practices: what is actually being kept private????TangentialNot addressed 
27Standardized and effective workflow for dealing with attribute release???OperationalIIP-IDP05, IIP-IDP06, arguably IIP-MD04Partial; IIP-IDP05 is useful for support of entity categories, and IIP-IDP06 is useful to the extent that including md:RequestedAttributes is part of the operational solution. IIP-MD04 is useful to the extent that consuming or excluding metadata simplifies the process
28Vendors charging fees for setup and support of SAMLSAML support should be part of base serviceOperationalOut of profile scope 
29Lack of framework/contract terms; change controls, support escalation???OperationalOut of profile scope 
30Lack of testing SP/IdP facilities (test SP, test IdP)Run a testing SP/IdP for validation purposes during initial integration testing?OperationalNot addressed 
31Knowledge gaps with some vendors on how SAML works.???Operational

Out of profile scope or

The entire document

 
32Advertised but unsupported functionality in metadata (artifact endpoints, etc.)Advertise only supported endpointsOperationalIIP-MD09; IIP-SP02; IIP-IDP02Partial; MA01-02 address listed encryption profiles. Arguably the metadata exchange requirements imply some support of this, but no specific requirements are listed.
33Availability of POP/mechanism for assessing riskInCommon: stronger focus on POP? [May be addressed in different workgroups]OperationalOut of profile scope 
34Publishing metadata contact info for security incident responseInclude security incident response (usually security or help desk) in metadataOperationalOut of profile scope 
35ForceAuthn: IdPs not ensuring user is reauthenticatedVerify function of reauth before resetting authninstantOperationalIIP-IDP08Yes; at least to the extent we can define it across authN methods.
36ForceAuthn: SPs not checking authninstantVerify (or allow verification) of authninstant currencySoftware/OperationalNot addressed 
37OASIS Standards have not been updated with Errata, current Errata out-of-dateRecommend in report-out of WG that someone be resourced to update the Errata and a modify the standard to include the changes from Errata (working with OASIS) (Scott C says someone has informally volunteered to do this. Who?)StandardsOut of profile scopePartial; Addressed separately (Scott C, Eric), but not included in the OASIS repository.
38Review with REFEDS once a solid draft is doneNick to check in with Nicole on thisStandardsOut of profile scopeNick
39Research collaboration requirements for adoption of a persistent nameIDUse of persistent nameID or other mechanism to enable seamless collaboration across multiple SPs in a research organization.OperationalOut of profile scope?Scott K
40"Ready For Collaboration" entity category for IdPsDescription of an entity category that would signal that an IdP is configured for ease of collaboration with no manual intervention by operators, does not re-assign ePPN, and/or uses persistent nameID... etc. TBDOperationalOut of profile scope?David W
41"Red IdPs"eduGAIN has the "ECCS" service (https://technical.edugain.org/eccs/index.html) for highlighting various levels of IdP operability. Tom Scavo has a script that looks for "dead" IdPs. Is there some useful baseline for IdP operability or interoperability that this group would recommend and could it be tested for?OperationalOut of profile scope, in scope for later work of a successor to this groupNick / Scott Koranda
42Don't respond to Unsolicited assertions.

(Still working to clarify specific requirement)

SoftwareNot addressed 
43 Include language in SAML2int regarding support for multiple IdPs asserting against access to the same resource URL/entityID. (I.e., clarify that federation presumes cloud vendors can support multiple IdPs and discovery, not just externalized authentication)Software/OperationalFollowup to item 14 to be addressed in SAML2INT work 
44Attribute or NameID values too short or disallow legal XML charactersMinimum implementation requirements for attribute/nameid values (in particular xs:string) length and legal charactersSoftware  
45Lack of scope validationAttribute scopes can be validated against allowed scopes defined in metadata (or elsewhere?).Software.  
46Lack of time synchronization (separate from, but as important as clockskew)Require that SP and IdP deployments use time synchronization against time serversOperationalNot addressed 
47Java and md5/sha1 certificate supportDeployment profile should call out that all certs should be signed with modern signing algorithms to avoid being rejected by cryptographic code that is increasingly aggressive about rejecting older signature types, even in cases where signature verification is not required.OperationalNot addressed 
48Binding of an identifier to its issuer or more broadly checking scope

See: http://www.economyofmechanism.com/office365-authbypass.html

Issues that need to be remedied in a rev of saml2int: require binding of an asserted identifier to the public key in metadata of its original issuer.

Software/OperationalNot addressed 

...