Hi Indunil, Please make sure this behavior is properly explained in the documentation, with references to the spec.
Cheers, Ruwan On Mon, Mar 12, 2018 at 10:30 AM, Indunil Upeksha Rathnayake < [email protected]> wrote: > > > 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
