On the initiation of this working group, but prior to the first meeting, Walter sent an email titled "Kicking Things Off" to the group mailing list.
The email asked:
1. From both an IdP and SP perspective, what have been the most common challenges you have encountered when attempting to interoperate with federated partners?
2. To what extent were the challenges from question one a result of operational practices of the site vs. software configuration vs. limitations in the SAML implementation used?
This table (you're welcome, Scott!) is an attempt to capture the issues listed in that thread.
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.
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.
| Issue | Issue restated as requirement | Limitation | Captured (By) | Who's Tracking |
|---|---|---|---|---|
| Manual exchange of metadata or (worse) raw config into | Automated, ongoing metadata exchange and validation | Software/Operational | Yes | |
| Security risk/change control risk inherent in one-time MD exchange | Automated, ongoing metadata exchange and validation | Operational | Yes | |
| Lack of precise documentation and sloppy use of SAML constructs (in custom deployments) | More specificity for use of some specific SAML features | Software | ||
| SP-initiated SSO as a "special" case | Support for SP-initiated SSO | Software | ||
| Lack of deep link support | Support for deep linking | Software/Operational | ||
| Use of frames that break with 3rd party cookies | Keeping authentication screens as top level windows (not iframes) | Operational | ||
| Lack of dynamic provisioning/entitlement-like attribute based authZ | Support for attributes indicating group membership/entitlements (when customers handle authZ) | Software/Operational | ||
| Lack of focus on AuthZ space and support | As above? | Operational | ||
| Lack of clock skew allowance | Support for clock skew | Software | ||
| Lack of encryption support | Support for encryption (and current encryption, e.g., SHA256 signatures) [RH: meaning "and current signatures" or "and current algorithms"]. | Software | Yes | |
| Requiring valid (vendor signed and/or expiring) certs | Support for non-expiring keys/certs | Software/Operational | ||
| Lack of discovery support/portable links (w/o hard coded IdP refs) | Support for discovery services | Software | ||
| Hard coded 1:1 SP:IdP models | Support for multiple IdPs | Software/Operational | ||
| Require non-opaque, non-transient NameID (rather than attribute) | Support for account identifiers in attributes (rather than NameIDs) | Software/Operational | ||
| Requiring literal account IDs be asserted by IdP | Support for identifier mapping (i.e., IdP ID is mapped to an internal account ID) | Operational | ||
| AuthnContextClass: not specifying at SP, but failing if PPT not used by IdP | Specify ACC; if unspecified, accept any ACC | Software | ||
| AuthnContextClass: can't handle locally defined AuthnContextClasses | Allow support of extended ACC's (as part of site-specific configuration | Software | ||
| AuthnContextClass: no "step-up" support | Support use of "step-up" authentication (re-auth with new ACC and poss ForceAuthn | Software/Operation | ||
| Assuming Logout URL exists | Verify advertised IdP SLO endpoint before directing user there | Software | ||
| Logoff handling | ??? | SAML | ||
| Expectations of SLO | ??? | Operational | ||
| Browser cookie behavior impacting functionality (sessions not clearing, etc) | ??? | SAML | ||
| Attribute release standards for IdPs | ??? | Operational | ||
| Attribute release: suppressing grad students (FERPA concerns) | ??? | Operational | ||
| Privacy practices: what is actually being kept private? | ??? | Tangential | ||
| Standardized and effective workflow for dealing with attribute release | ??? | Operational | ||
| Vendors charging fees for setup and support of SAML | SAML support should be part of base service | Operational | ||
| Lack of framework/contract terms; change controls, support escalation | ??? | Operational | ||
| Lack of testing SP/IdP facilities (test SP, test IdP) | Run a testing SP/IdP for validation purposes during initial integration testing? | Operational | ||
| Knowledge gaps with some vendors on how SAML works. | ??? | Operational | ||
| Advertised but unsupported functionality in metadata (artifact endpoints, etc.) | Advertise only supported endpoints | Operational | ||
| Availability of POP/mechanism for assessing risk | InCommon: stronger focus on POP? [May be addressed in different workgroups] | Operational | ||
| Publishing metadata contact info for security incident response | Include security incident response (usually security or help desk) in metadata | Operational | ||
| ForceAuthn: IdPs not ensuring user is reauthenticated | Verify function of reauth before resetting authninstant | Operational | ||
| ForceAuthn: SPs not checking authninstant | Verify (or allow verification) of authninstant currency | Software/Operational |
Note: not included here are some recommended reference links, as those have been captured in the working group's list of references already