This page has been deprecated. It was an intermediate work product. The final report and the completed saml2int profile should be used as primary sources of information.


This table is a result of copying the original Implementation Profile WG Interop Issues List, and modifying it for use by the deployment profile WG.

Column 1 captures the identified issues.

Column 2 attempts to recast each issue as a "requirement" (note, the recasting may not work, so this column should be looked at skeptically).

Column 3 categorizes the issue per Walter's note.

Column 4 is for record keeping to identify whether/where each issue is captured and addressed in the work put forward by the working group.

Column 5 is a Yes/No indicator of whether the issue is in-scope for the work of the deployment profile WG

 

This list will also be used ongoing as a "parking lot" for any issues that are raised in discussion that are not immediately captured in the profile documentation.

 

#IssueIssue restated as requirementLimitationResolvedHow ResolvedIn-Scope for Deployment ProfileCandidate ForNotesQuestions and Answers
1Manual exchange of metadata or (worse) raw config intoAutomated, ongoing metadata exchange and validationSoftware/OperationalYesImplementation profile IIP-MD04, IIP-ME04YesSaml2int  
2Security risk/change control risk inherent in one-time MD exchangeAutomated, ongoing metadata exchange and validationOperationalYesImplementation profile IIP-ME03, IIP-ME04YesSaml2int  
3Lack of precise documentation and sloppy use of SAML constructs (in custom deployments)More specificity for use of some specific SAML featuresSoftwareYesImplementation profile - throughoutYesDocumentation profile  
4SP-initiated SSO as a "special" caseSupport for SP-initiated SSOSoftwareYesImplementation profile IIP-SSO01YesSaml2int  
5Lack of deep link supportSupport for deep linkingSoftware/OperationalYesImplementation profile IIP-SP13YesSaml2int  
6Use of frames that break with 3rd party cookiesKeeping authentication screens as top level windows (not iframes)Operational  YesSaml2int  
7Lack of dynamic provisioning/entitlement-like attribute based authZSupport for attributes indicating group membership/entitlements (when customers handle authZ)Software/Operational  YesApplication profile  
8Lack of focus on AuthZ space and supportSupport for attributes indicating group membership/entitlements (when customers handle authZ)Operational  YesApplication profile  
9Lack of clock skew allowanceSupport for clock skew and NTPSoftwareYesImplementation profile IIP-G01,YesSaml2intalso recommend adding recommendation for consumption of time server service in a deployment profile 
10Lack of encryption supportSupport for XML encryption at the SPSoftwareYesImplementation profile IIP-SP13, IIP-SSO04, IIP-MD09, IIP-SP02,IIP-MD10, IIP-MD11, Section 2.5 (IIP-ALG01 - 06), IIP-IDP11, IIP-IDP19YesSaml2int  
11Lack of key rollover supportSupport for key rolloverSoftwareYesImplementation profile Section 2.1.3 (IIP-MD07, IIP-MD08, IIP-SP13, IIP-IDP19)YesSaml2int  
12Requiring valid (vendor signed and/or expiring) certsSupport for long-lived, self-signed certs, which may or may not be expiredSoftware/OperationalYesImplementation profile IIP-MD05, IIP-MD03, IIP-MD11YesSaml2int  
13Lack of discovery support/portable links (w/o hard coded IdP refs)Support for discovery servicesSoftwareYesImplementation profile IIP-SP09YesSaml2int  
14Hard coded 1:1 SP:IdP modelsSupport for multiple IdPsSoftware/Operational  YesSaml2int  
15Require non-opaque, non-transient NameID (rather than attribute)Support for account identifiers in attributes (rather than NameIDs)Software/OperationalPartial; 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?Implementation profile IIP-SP03, IIP-SP08, IIP-IDP12, IIP-SSO05YesSaml2int  
16Requiring literal account IDs be asserted by IdPSupport for identifier mapping (i.e., IdP ID is mapped to an internal account ID)OperationalBest 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.Implementation profile IIP-SP03YesSAML subject-id profile  
17AuthnContextClass: not specifying at SP, but failing if PPT not used by IdPSpecify ACC; if unspecified, accept any ACC (unless there is a security reason not to)SoftwarePartial; 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).Implementation profile IIP-IDP10YesSaml2int  
18AuthnContextClass: can't handle locally defined AuthnContextClassesAllow support of extended ACC's (as part of site-specific configuration)SoftwarePossibly; arguably inferable from IIP-IDP10, but it is not clear from IDP10 that IdP must support arbitrary values for ACC.Implementation profileYesApplication profile  
19AuthnContextClass: no "step-up" supportSupport use of "step-up" authentication (re-auth with new ACC and poss ForceAuthnSoftware/Operation  Yes No (No current accepted practice)Application profileApp profile at best - Some of these are really hard - probably need to update saml2int and then work backwards from gaps 
20Assuming Logout URL existsVerify advertised IdP SLO endpoint before directing user thereSoftwarePartial; Says IdP must support SLO, but does not indicate that SPs must honor IdP metadata. Do we need an SP requirement here?Implementation profile Section 4.5 (IIP-IDP17-20)YesSaml2int  
21Logoff handling???SAMLProbablyImplementation profile Section 4.5 (IIP-IDP17-20)YesSaml2int  
22Expectations of SLO???OperationalPartial; (assuming this is largely a duplicate of issue 20)Implementation profile Section 4.5 (IIP-IDP17-20)YesSaml2int  
23Browser cookie behavior impacting functionality (sessions not clearing, etc)???SAML  No Probably needs to be called out, somehow, about this behavior 
24Attribute release standards for IdPs???Operational  YesInCommon "new rules"Perhaps attribute release recommendations SHOULD be part of this group's final report 
25Attribute release: suppressing grad students (FERPA concerns)???OperationalIs this and 24 about configuring conditional release of data from specfiic users???? Probably needs to be reworded, less specific, ask LIGO folks (Scott K)  
26Privacy practices: what is actually being kept private????Tangential  No   
27Standardized and effective workflow for dealing with attribute releaseConfiguring attribute release based on available contextOperationalPartial; 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 processImplementation profile IIP-IDP05, IIP-IDP06, arguably IIP-MD04Yes NoApplication profileOnly addressed in the context of the new SAML subject-id profile 
28Vendors charging fees for setup and support of SAMLSAML support should be part of base serviceOperational  Yes NoInCommon "new rules"  
29Lack of framework/contract terms; change controls, support escalation???Operational  Yes NoInCommon "new rules"  
30Lack of testing SP/IdP facilities (test SP, test IdP)Run a testing SP/IdP for validation purposes during initial integration testing?Operational  Yes No Recommendation in a final report 
31Knowledge gaps with some vendors on how SAML works.???Operational  No   
32Advertised but unsupported functionality in metadata (artifact endpoints, etc.)Advertise only supported endpointsOperationalPartial; MA01-02 address listed encryption profiles. Arguably the metadata exchange requirements imply some support of this, but no specific requirements are listed.Implementation profile IIP-MD09; IIP-SP02; IIP-IDP02YesSaml2int  
33Availability of POP/mechanism for assessing riskInCommon: stronger focus on POP? [May be addressed in different workgroups]Operational  No Deprecated by baseline practices 
34Publishing metadata contact info for security incident responseInclude security incident response (usually security or help desk) in metadataOperational  YesR&E profileInCommon behavioral/Sirtfi thing 
35ForceAuthn: IdPs not ensuring user is reauthenticatedVerify function of reauth before resetting authninstantOperationalYes; at least to the extent we can define it across authN methods.Implementation profile IIP-IDP08YesSaml2int  
36ForceAuthn: SPs not checking authninstantVerify (or allow verification) of authninstant currencySoftware/Operational  Yes No (Seen more as advice than profile)Application profile  
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?)StandardsPartial; Addressed separately (Scott C, Eric), but not included in the OASIS repository.NoNoted 
Not part of profile, but may be worth pursuing separately. 
38Review with REFEDS once a solid draft is doneNick to check in with Nicole on thisStandardsNick Tangential   
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.OperationalScott K YesApplication profile  
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. TBDOperationalDavid W Yes/Tangential?Application (or federation) profile  
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?OperationalNick / Scott Koranda YesR&E profilePossibly recommend inserting entity attribute for 'red' IdPs 
42Don't respond to Unsolicited assertions.(Still working to clarify specific requirement)Software  No
  
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/Operational  YesSaml2intFollowup 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 charactersSoftwareYesImplementation profile IIP-G03YesSaml2int  
45Lack of scope validationDEDUPLICATE into binding ID to issuer one) Attribute scopes can be validated against allowed scopes defined in metadata (or elsewhere?).Software.  YesSaml2int  
46Lack of time synchronization (separate from, but as important as clockskew)Require that SP and IdP deployments use time synchronization against time serversOperational  YesSaml2int  
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.Operational  YesSaml2int  
48Binding of an identifier to its issuer or more broadly checking scopeSee:http://www.economyofmechanism.com/office365-authbypass.htmlSoftware/Operational  YesSaml2int  
49Broken or missing errorURL in IdP metadataRecommend an errorURL in IdP metadata. If an IdP does not have a working errorURL in metadata, it should be tagged with hide-from-discovery.Operational  Yes   
50No standard attribute setDefine or reference a standard attribute set. (I.e., do we use eduPerson LDAP objectclass vs. InCommon POP/Wiki vs. some broader spec)Operational  Yes No Added during 10/6 meeting discussion 

Note: not included here are some recommended reference links, as those have been captured in the working group's list of references already

  • No labels