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
> On Wed, Feb 28, 2018 at 7:56 AM, Johann Nallathamby <joh...@wso2.com>
>> Hi Indunil,
>> On Tue, Feb 27, 2018 at 3:56 PM, Indunil Upeksha Rathnayake <
>> indu...@wso2.com> wrote:
>>> 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  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 , 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
>>> MUST be included in the <saml2p:Extensions> element of the SAML
>>> <saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
>>> <http://eidas.europa.eu/saml-extensions>"* ...>
>>> <eidas:RequestedAttribute FriendlyName="D-2012-17-EUIdentifier"
>>> isRequired="false" />
>>> <eidas:RequestedAttribute FriendlyName="LegalPersonIdentifier"
>>> isRequired="true" />
>>> - Apart from the attributes, for indicating whether an
>>> authentication request is made by a private sector or public sector SP,
>>> 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 , 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
>>> 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
>>> 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
>> +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.
>>> Really appreciate your suggestions and comments.
>>>  https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/How+
>>>  https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/2016
>>>  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.
>> Mobile: *+94 77 7776950*
>> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
>> Medium: *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
Architecture mailing list