On Thu, Mar 15, 2018 at 6:55 AM, Harsha Thirimanna <hars...@wso2.com> wrote:
> > > On Mon, 12 Mar 2018, 13:48 Johann Nallathamby, <joh...@wso2.com> wrote: > >> >> >> On Mon, Mar 12, 2018 at 10:58 AM, Indunil Upeksha Rathnayake < >> indu...@wso2.com> wrote: >> >>> 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. >>> >>> +1 for this. This is something we planned to have in IS 5.3.0, but >> couldn't complete due to time constraints. >> >>> >>> 1. >>> 2. 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. >>> >>> How would you choose which dialect to use in the runtime, if one SP can >> have multiple dialects? Remember in our implementation claim is not unique. >> Dialect + claim is unique. So if we don't have the dialect in the >> authentication request, it might be not straightforward to map claims >> between dialects. >> > > Yes , this will not possible as Johan said. > > Because of internal data structure and the implementation, there can be > same claim Uri in multiple dialect. > But theoretically claim Uri is kind of a name space and dialect is just > grouping of multiple claims. So the namespace should be unique in any > place. Don't we need to enforce that in our documentation even we support > it internally to have same claims in multiple dialect. Is that prcticle to > have such a same claim in different dialect ? > This is been implemented as follows. Multiple SP dialects can be configured from UI, so that "http://eidas.europa.eu/attributes/naturalperson"; and " http://eidas.europa.eu/attributes/legalperson"; will be considered as two dialects and all the eIDAS claims will be shipped by default in product. So we will be configured them as full claim URIs with appended claim dialect. > > > >>> 1. 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? >>> >>> I would rather prefer to have it like the following. >> 1. If configured claim set is null and service provider is requesting >> attributes, send those attributes. >> 2. If at least one claim has been configured in service provider, send >> the intersection of configured claims and requested claims. >> >> This will give us a way to control requested claims if needed. But also >> not force the admins to always configure requested claims for each service >> provider. I don't see any purpose in providing two ways (configuration and >> request) to send back claims to the service provider, unless it is used to >> control access. >> >>> >>> - >>> >>> >>> - 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? >>> >>> Common solution could be as explained above. >> >> Regards, >> Johann. >> >>> >>> - >>> >>> >>> Appreciate your ideas on this. >>> >>> [1] https://ec.europa.eu/cefdigital/wiki/display/ >>> CEFDIGITAL/eIDAS+Profile >>> [2] https://docs.google.com/document/d/1uF7qV780SspZHa4hCoiMvaZqjdF9I >>> apnj8kSNaEUJDU/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 >>> >> >> >> >> -- >> >> *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* >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> -- Indunil Upeksha Rathnayake Software Engineer | WSO2 Inc Email indu...@wso2.com Mobile 0772182255
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
