Hi, In order to support eIDAS profile in IS, as per the 4 eIDAS specifications in [1], there are a set of requirements to be considered including message format, cryptographic requirements etc. Those requirements has been summarized in [2].
This is regarding the handling and inclusion of attributes into exchanged messages in eIDAS network. As per the eIDAS SAML attribute profile specification, requesting user attributes MUST be carried out dynamically by including them in a <saml2p:AuthnRequest>. There are a set of mandatory and optional attributes according to the eIDAS minimum data sets for natural and legal persons (i.e. Natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name [3]. A legal person is any human being, firm, or government agency that is recognized as having legal rights and obligations, such as having the ability to enter into contracts, to sue, and to be sued [4]). The eIDAS attribute profile support has been currently implemented as follows. 1. Include eIDAS attribute profile support in travelocity sample for testing purposes. 2. Process the eIDAS attributes in authentication request and send to the requested attributes to framework. 3. Introduced a new dialect for "http://eidas.europa.eu/attributes"; and configure it in the SP Claim Configuration as the SP Claim mapping Dialect. Include support for multiple SP dialects considering the support for multiple SAML attribute profiles as eIDAS. 4. In order to get the user claims which are mapped to the SP dialect, in the framework side filter out based on the SP dialect to local claim mappings, if SP claim dialect is configured. 5. Process the response retrieved from the framework and send the response to eIDAS network, in appropriate format. Appreciate your comments and suggestions on above approach and please find the following concerns. - With the requested attributes in the authentication request, as per the specification, we may send the AttributeConsumingServiceIndex as well. Currently we have only the basic attribute profile support in SAML. So when filtering out the requested claims, we need to send both the requested claims in SP configuration and the claims in the request, if AttributeConsumingServiceIndex is retrieved. WDYT? - As per the current implementation for eIDAS support, first we give priority to the SP configured claims set, if it's not available consider the requested claims in the request. With the oauth request object feature, the logic for filtering out the requested claims is somewhat different (Requested claims should be configured in SP claims configuration, and only sending the requested claims in request which are configured in SP). So I think we need to come up with a common solution, if we moving the requested claim filtering to framework. Shall we use this approach as the common? Appreciate your ideas on this. [1] https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+Profile [2] https://docs.google.com/document/d/1uF7qV780SspZHa4hCoiMvaZqjdF9Iapnj8kSNaEUJDU/edit?usp=sharing [3] https://en.wikipedia.org/wiki/Natural_person [4] https://en.wikipedia.org/wiki/Legal_person Thanks and Regards On Mon, Mar 12, 2018 at 10:30 AM, Indunil Upeksha Rathnayake < indu...@wso2.com> wrote: > > > On Wed, Feb 28, 2018 at 5:15 PM, Dulanja Liyanage <dula...@wso2.com> > 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 <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. >> > > > > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Email indu...@wso2.com > Mobile 0772182255 > -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email indu...@wso2.com Mobile 0772182255
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
