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.
On Wed, Feb 28, 2018 at 7:56 AM, Johann Nallathamby <joh...@wso2.com> wrote: > Hi Indunil, > > On Tue, Feb 27, 2018 at 3:56 PM, Indunil Upeksha Rathnayake < > indu...@wso2.com> 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 indu...@wso2.com >> 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.
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
