Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Indunil Upeksha Rathnayake]

Hi,

Thanks for all of your ideas. Please note that with this implementation,
following extensions in SAML has been introduced for the following reasons.

EidasExtensionProcessor - process the SAML extension and retrieve the
required attribute list.
EidasSAMLAssertionBuilder - validate whether all the required set of
attributes are present and set the name format URI as required.
EidasSPInitSSOAuthnRequestValidator - Validate the authentication request
as per the eIDAS specification (Comaprison of RequestedAuthnContext should
be minimum, ForceAuthn MUST be set to true, isPassive SHOULD be set to
false, NameIDPolicy SHOULD be included etc).


As I have mentioned in [1], there are set of Requirements for Cryptography
in eIDAS specification. Most of requirements can be achieved currently,
there were few to be considered, currently analyzing them.

[1] https://docs.google.com/document/d/1uF7qV780SspZHa4hCoiMvaZq
jdF9Iapnj8kSNaEUJDU/edit?usp=sharing

On Mon, Mar 12, 2018 at 12:15 PM, Johann Nallathamby 
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 . 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.
>
>>
>>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
>

+1

>
>>-
>>
>>
>>- 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 

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Indunil Upeksha Rathnayake]

On Thu, Mar 15, 2018 at 6:55 AM, Harsha Thirimanna  wrote:

>
>
> On Mon, 12 Mar 2018, 13:48 Johann Nallathamby,  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 . 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 

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Harsha Thirimanna]

On Mon, 12 Mar 2018, 13:48 Johann Nallathamby,  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 . 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 ?



>>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.
>
>>
>>-
>>
>>
>> 

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Johann Nallathamby]

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 . 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.

>
>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/1uF7qV780SspZHa4hCoiMvaZq
> jdF9Iapnj8kSNaEUJDU/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 
>> 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 

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Indunil Upeksha Rathnayake]

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 . 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 
> 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 
>> 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 

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Ruwan Abeykoon]

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 <
indu...@wso2.com> wrote:

>
>
> On Wed, Feb 28, 2018 at 5:15 PM, Dulanja Liyanage 
> 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 
>> 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  and 
 *
MUST be included in the  element of the SAML
AuthnRequest.*

 Ex:

 >>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#;
 *xmlns:eidas="http://eidas.europa.eu/saml-extensions 
 "* ...>
  
  **
*public*
**
   >>>
 Name="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
 isRequired="false" />
   >>>
 Name="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
 isRequired="true" />

  
  .
 


- Apart from the attributes, for indicating whether an
authentication request is made by a private sector or public sector SP, 
 the
defined element * MUST be present* either in the
 element of SAML metadata or in the 
element of a .


 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 

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Indunil Upeksha Rathnayake]

On Wed, Feb 28, 2018 at 5:15 PM, Dulanja Liyanage  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 
> 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  and 
>>> *
>>>MUST be included in the  element of the SAML
>>>AuthnRequest.*
>>>
>>> Ex:
>>>
>>> >> xmlns:ds="http://www.w3.org/2000/09/xmldsig#;
>>> *xmlns:eidas="http://eidas.europa.eu/saml-extensions 
>>> "* ...>
>>>  
>>>  **
>>>*public*
>>> **
>>>>> 
>>> Name="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
>>> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
>>> isRequired="false" />
>>>>> 
>>> Name="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
>>> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
>>> isRequired="true" />
>>>
>>>  
>>>  .
>>> 
>>>
>>>
>>>- Apart from the attributes, for indicating whether an
>>>authentication request is made by a private sector or public sector SP, 
>>> the
>>>defined element * MUST be present* either in the
>>> element of SAML metadata or in the 
>>>element of a .
>>>
>>>
>>> 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] 

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Dulanja Liyanage]

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.

On Wed, Feb 28, 2018 at 7:56 AM, Johann Nallathamby  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  and 
>> *
>>MUST be included in the  element of the SAML
>>AuthnRequest.*
>>
>> Ex:
>>
>> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#;
>> *xmlns:eidas="http://eidas.europa.eu/saml-extensions 
>> "* ...>
>>  
>>  **
>>*public*
>>  **
>> >  
>> Name="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
>>  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
>> isRequired="false" />
>> >  
>> Name="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
>>  NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
>> isRequired="true" />
>>
>>  
>>  .
>> 
>>
>>
>>- Apart from the attributes, for indicating whether an authentication
>>request is made by a private sector or public sector SP, the defined
>>element * MUST be present* either in the
>> element of SAML metadata or in the 
>>element of a .
>>
>>
>> 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
>> Emailindu...@wso2.com
>> Mobile   0772182255 <077%20218%202255>
>>
>
>
>
> --

Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Johann Nallathamby]

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  and 
> *
>MUST be included in the  element of the SAML
>AuthnRequest.*
>
> Ex:
>
>  xmlns:ds="http://www.w3.org/2000/09/xmldsig#;
> *xmlns:eidas="http://eidas.europa.eu/saml-extensions 
> "* ...>
>  
>  **
>*public*
>   **
> 
> Name="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
> isRequired="false" />
> 
> Name="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
>   NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 
> isRequired="true" />
>
>  
>  .
> 
>
>
>- Apart from the attributes, for indicating whether an authentication
>request is made by a private sector or public sector SP, the defined
>element * MUST be present* either in the 
>element of SAML metadata or in the  element of a
>.
>
>
> 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
> Emailindu...@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
*
Medium: *https://medium.com/@johann_nallathamby
*
Twitter: *@dj_nallaa*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [Architecture] [IAM] eIDAS profile support for SAML

[Indunil Upeksha Rathnayake]

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  and
*
   MUST be included in the  element of the SAML
   AuthnRequest.*

Ex:

http://www.w3.org/2000/09/xmldsig#;
*xmlns:eidas="http://eidas.europa.eu/saml-extensions
"* ...>
 
 **
   *public*
**
   http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier;
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="false" />
   http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier;
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
isRequired="true" />
   
 
 .



   - Apart from the attributes, for indicating whether an authentication
   request is made by a private sector or public sector SP, the defined
   element * MUST be present* either in the 
   element of SAML metadata or in the  element of a
   .


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


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
Emailindu...@wso2.com
Mobile   0772182255
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev