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
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to