On Wed, Feb 28, 2018 at 5:15 PM, Dulanja Liyanage <[email protected]> wrote:
> If extensions are coming in the SAML AuthnRequest from the SP, then, IIRC, > that *same extension* will be copied to the AuthnRequest going to the > Federated IdP. Is that behaviour acceptable for this scenario? Please > validate that. > If that is a federated scenario, where the IDP is not IS, we need to disable the eIDAS extension processing and just forwarded the request as it is. > > On Wed, Feb 28, 2018 at 7:56 AM, Johann Nallathamby <[email protected]> > wrote: > >> Hi Indunil, >> >> On Tue, Feb 27, 2018 at 3:56 PM, Indunil Upeksha Rathnayake < >> [email protected]> wrote: >> >>> Hi, >>> >>> eIDAS (electronic IDentification, Authentication and trust Services) is >>> an EU regulation on electronic identification and trust services for >>> electronic transactions in the internal market. The eIDAS interoperability >>> framework including its national entities (eIDAS-Connector and >>> eIDAS-Service) need to exchange messages including personal and technical >>> attributes to support cross-border identification and authentication >>> processes (Please refer [1] for more information). For the exchange of >>> messages, the use of the SAML 2.0 specifications has been agreed and there >>> are eIDAS compliant set of technical specifications in [2], which Member >>> States of EU to use to develop their own eIDAS-compliant implementation. >>> >>> >>> As per the "eIDAS SAML Message Format" specification, handling and >>> inclusion of attributes into exchanged messages is defined as follows. >>> >>> - Attributes MUST be requested as <eidas:RequestedAttributes> and >>> *<eidas:RequestedAttributes> >>> MUST be included in the <saml2p:Extensions> element of the SAML >>> AuthnRequest.* >>> >>> Ex: >>> >>> <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" >>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; >>> *xmlns:eidas="http://eidas.europa.eu/saml-extensions >>> <http://eidas.europa.eu/saml-extensions>"* ...> >>> ............ >>> *<saml2p:Extensions>* >>> *<eidas:SPType>public</eidas:SPType>* >>> *<eidas:RequestedAttributes>* >>> <eidas:RequestedAttribute FriendlyName="D-2012-17-EUIdentifier" >>> >>> Name="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier"; >>> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" >>> isRequired="false" /> >>> <eidas:RequestedAttribute FriendlyName="LegalPersonIdentifier" >>> >>> Name="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier"; >>> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" >>> isRequired="true" /> >>> </eidas:RequestedAttributes> >>> </saml2p:Extensions> >>> ............. >>> </saml2p:AuthnRequest> >>> >>> >>> - Apart from the attributes, for indicating whether an >>> authentication request is made by a private sector or public sector SP, >>> the >>> defined element *<eidas:SPType> MUST be present* either in the >>> <md:Extensions> element of SAML metadata or in the <saml2p:Extensions> >>> element of a <saml2p:AuthnRequest>. >>> >>> >>> As per the SAML Core specification in [3], SAML Extensions is an >>> optional element in SAML 2.0, allowing arbitrary information to be passed >>> to the identity provider which are agreed on between the communicating >>> parties. As mentioned above, eIDAS attributes should be included within >>> SAML extension element. >>> >>> >>> Currently in IS, *SAML Extensions processing *has not taken into the >>> consideration. So that, in order to have eIDAS profile support for SAML, >>> that should be considered. Please find the following proposed >>> implementation. >>> >>> 1. *Register a set of SAML Extension Processors* - extensible >>> mechanism where we can include any extension processing >>> 2. *eIDAS Extension Processor *- specifically handled the eIDAS >>> extension >>> 3. *Invoke the processors when building the SAML assertion* >>> - Consider that all the necessary attributes are configured as >>> the SP requested claims >>> - In the eIDAS processor, filtering out the requested attributes >>> based on the "RequestedAttributes" elements in the authentication >>> request >>> >>> >> +1 for the approach. But make sure we don't have to configure FQCN in >> files and make only one processor work at a given time. Processors should >> be picked dynamically based on the request. I think like the other >> processors we have, you can extend from AbtractIdentityHandler and do this >> via the HandlerManager we have in identity.core. >> >> One of the concerns I have is about "RequestedAttributes". We are >> assuming that the required attributes are configured for the service >> providers. This coordination is not possible between countries, unless they >> all agree on a standard set of attributes always, and there are too many >> service providers to do this. I think we need to fix this and have a way >> to dynamically request attributes without depending on the service provider >> configuration. OIDC also suffers from this same limitation. I think we need >> to fix this problem with this effort. >> >> Regards, >> Johann. >> >>> >>> - >>> >>> >>> Really appreciate your suggestions and comments. >>> >>> >>> [1] https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/How+ >>> does+it+work+-+eIDAS+solution >>> [2] https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/2016 >>> /12/16/eIDAS+Technical+Specifications+v.+1.1 >>> [3] https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf >>> >>> Thanks and Regards >>> >>> -- >>> Indunil Upeksha Rathnayake >>> Software Engineer | WSO2 Inc >>> Email [email protected] >>> Mobile 0772182255 <077%20218%202255> >>> >> >> >> >> -- >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile: *+94 77 7776950* >> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby >> <http://www.linkedin.com/in/johann-nallathamby>* >> Medium: *https://medium.com/@johann_nallathamby >> <https://medium.com/@johann_nallathamby>* >> Twitter: *@dj_nallaa* >> > > > > -- > Thanks & Regards, > Dulanja Liyanage > Lead, Platform Security Team > WSO2 Inc. > -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email [email protected] Mobile 0772182255
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
