Kantara Comments on the eRecognition SAML profile (draft)
Abstract
This eGov Work Group document shall provide a feedback to the public consultation on the Dutch eRecognition SAML profile.
Editors
Rainer Hörbe
(please add yourself here when you are contributing)
Intellectual Property Notice
The eGov WG Group operates under Creative Commons Share-Alike Attribution IPR Option and the publication of this document is governed by the policies outlined in this option.
1 General findings on document “Interface Specification”
1.1 Conflict between 2.1 and 3.1
2048bit key length + SHA-2: this is good, should have be done in STORK as well. Government needs to drive minimum security level. However, SSL 3.0 and TLS 1.0 do not allow SHA-2 HMACs. TLS 1.2 is not very widely deployed. This would need some action.
1.2 Minimum certificate requirements
Re 3.1: Therefore also key length requirements to one type of certificate do not improve security, because an attacker will usually follow the weakest attack path.
1.3 Relay State
Re 2.2.3: Message must relay state? SP-side relay state and cookies are current best practice. 80-byte limit applies to URLs only.
1.4 AuthnContextClasses
9.2.1: IANA is starting a registry of assurance levels (quite new, not yet in production). The eRcognition classes would be a candidate for registration:
http://www.iana.org/assignments/loa-profiles/loa-profiles.xml
2 Expert Advice public interface eRecognition v1.4
2.1 Relationships with other standards (1.6)
“eRecognition interface is a specific profile SAML v2.0”.
This is not good enough. SAML 2.0 is a quite generic framework with many options and degrees of freedom. To achieve interoperability specific profiles are required. The current best practice has evolved into the Kantara SAML eGov Interoperability Profile. See http://kantarainitiative.org/confluence/x/SgCgAw for detailed information.
“Relationship to ISO27001”. This is probably not the correct question. For federations a classical PDCA-type risk management system is not appropriate[1]. Federations need Trust Frameworks, and while there are no established standards by ISO or ITU-T, Kantara, Open Identity Exchange and other organizations are providing services for improved interoperability.
SHA-2 and TLS: As mentioned in 1.1 these rules are inconsistent.
2.2 Scope of SAML
“The scope of SAML is defined by WebSSO and SLO.”
This is incomplete. At least an attribute profile (URN) and Metadata specs are being used. IdP Discovery might be used.
3 Conclusion
3.1 How does this SAML-profile compare to prevailing (international) profiles?
There are 2 widely used profiles. The OASIS SSTC SAML Conformance profiles proved a lightweight guidance on product implementation. However, they are not strict enough to enforce interoperability. Kantara Initiative (and its predecessor Liberty Alliance) developed a 2-level approach to profiles, where an interoperability profile guides developers to make products conformant to the standard, and deployment profiles specify the choices and optional extensions for specific deployments. A link to further information is given above at “Relationships with other standards (1.6)”.
While this is not yet a 100% solution for perfect interoperability, it proves to support very scalable federations primarily in the higher education and e-Government sectors.
eRecognition seems to be quite aligned with that profile. (A detailed step-by-step review should be conducted).
The deviations noted are:
Kantara SAML Interop. Profile | eRecognition Interface Spec. 1.4 |
2.2.2 Metadata Importation of multiple entities' metadata contained within an <md:EntitiesDescriptor> element MUST be supported. | Unclear if supported |
2.4 Attributes | RequestedAttributes the namespace: |
Service Provider implementations MUST support the inclusion of at least the following <saml2p:AuthnRequest> child elements and attributes (when appropriate): IsPassive NameIDPolicy
| isPassive: MAY NOT be included. NameIDPolicy: MAY NOT be included. (valid choice in deployment profile)
Remark: Assertion Consumer Service Index is prescribed within eRecognition. This is valid in the eGov profile, but not best practice because of the difficulty of ensuring consistency between local configuration and metadata)
|
2.5.3.2 Message Content must include Consent attribute | Consent MAY NOT be included |
|
|
There might be items in the eGov profile that are not specified in eRecognition.
Trust model (PKIX vs. Metadata not clear – might need more reading)
3.2 What could this mean for adoption and market acceptance of the eRecognition SAML profile?
a) We recommend improving the harmonization with the Kantara eGov profile that reflects current best practice for cross-enterprise deployments. The cost of deployment for new service providers is a key factor for market acceptance, and compliance with standards helps to drive down these costs. Investments in an optimized standard have a huge ROI in general (cross-industry figure is factor 40). A proof-of-concept for interoperability with a couple of relevant products should be the benchmark.
b) We recommend scrutinizing the design decisions in the eRecognition profile that deviate from other eGov profiles. The NL-specific protocol features should be limited to allow eRecognition the connect to the SAML WebSSO ecosystem as much as possible. These decisions should be well documented to clarify the issues for deployers.
c) We recommend to cooperate with other users in the government and higher education sectors who have experience in large scale deployments. Kantara Initiative and REFEDs are platforms created for this purpose. Other EU MS like Denmark and Finland have substantial experience in this field.
3.3 How is interoperability affected by the choices taken?
There was not enough time for this review to do a detailed gap analysis with other SAML 2.0 eGov deployment profiles. On the level of this initial analysis it would seem that the proposed standard is close to current industry practice.