[prev in list] [next in list] [prev in thread] [next in thread]
List: wsas-java-dev
Subject: Re: [Dev] [Architecture] [IAM] eIDAS profile support for SAML
From: Dulanja Liyanage <dulanja () wso2 ! com>
Date: 2018-02-28 11:57:29
Message-ID: CAK8c-DjC22wruDg_qbaLnFcHsSc+j6ZMPmarHWYp4SZhZiiqyg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <johann@wso2.com> wrote:
> Hi Indunil,
>
> On Tue, Feb 27, 2018 at 3:56 PM, Indunil Upeksha Rathnayake <
> indunil@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 indunil@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.
[Attachment #5 (text/html)]
<div dir="ltr">If extensions are coming in the SAML AuthnRequest from the SP, then, \
IIRC, that <i>same extension</i> will be copied to the AuthnRequest going to the \
Federated IdP. Is that behaviour acceptable for this scenario? Please validate \
that.<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 28, 2018 at \
7:56 AM, Johann Nallathamby <span dir="ltr"><<a href="mailto:johann@wso2.com" \
target="_blank">johann@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">Hi Indunil,<br><div \
class="gmail_extra"><br><div class="gmail_quote"><div><div \
class="m_-4742169165812312967h5">On Tue, Feb 27, 2018 at 3:56 PM, Indunil Upeksha \
Rathnayake <span dir="ltr"><<a href="mailto:indunil@wso2.com" \
target="_blank">indunil@wso2.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div>Hi,<br><br>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. <br><br><br>As per the "eIDAS SAML Message \
Format" specification, handling and inclusion of attributes into exchanged \
messages is defined as follows.<br><ul><li>Attributes MUST be requested as \
<eidas:RequestedAttributes> and <u><eidas:RequestedAttributes> MUST be \
included in the <saml2p:Extensions> element of the SAML \
AuthnRequest.</u></li></ul></div><div style="margin-left:80px">Ex: <br><span \
style="color:rgb(11,83,148)"><span \
style="font-size:8pt;font-family:Arial;font-style:normal"></span></span><pre \
style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"DejaVu \
Sans Mono""><span style="color:rgb(0,0,255)"><font \
size="1"><saml2p:AuthnRequest \
xmlns:saml2p="urn:oasis:names:<wbr>tc:SAML:2.0:protocol" xmlns:ds="<a \
href="http://www.w3.org/2000/09/xmldsig#" \
target="_blank">http://www.w3.org/20<wbr>00/09/xmldsig#</a>"<br> <span \
style="background-color:rgb(204,204,204)"><b>xmlns:eidas="<a \
href="http://eidas.europa.eu/saml-extensions" \
target="_blank">http://eidas.euro<wbr>pa.eu/saml-extensions</a>"</b></span> \
...><br> ............<br> <span \
style="background-color:rgb(204,204,204)"><b><saml2p:Extensions></b></span><br> \
<span style="background-color:rgb(204,204,204)"><b><eidas:SPType>public</eidas:SP<wbr>Type></b></span><br> <span \
style="background-color:rgb(204,204,204)"><b><eidas:RequestedAttributes></b></span><br> \
<eidas:RequestedAttribute FriendlyName="D-2012-17-EUIden<wbr>tifier"<br> \
Name="<a href="http://eidas.europa.eu/attributes/legalperson/D-2012-17-EUIdentifier" \
target="_blank">http://eidas.europa.eu/a<wbr>ttributes/legalperson/D-2012-1<wbr>7-EUIdentifier</a>"<br> \
NameFormat="urn:oasis:names:tc<wbr>:SAML:2.0:attrname-format:uri" \
isRequired="false" /><br> <eidas:RequestedAttribute \
FriendlyName="LegalPersonIdent<wbr>ifier"<br> Name="<a \
href="http://eidas.europa.eu/attributes/legalperson/LegalPersonIdentifier" \
target="_blank">http://eidas.europa.eu/a<wbr>ttributes/legalperson/LegalPer<wbr>sonIdentifier</a>"<br> \
NameFormat="urn:oasis:names:tc<wbr>:SAML:2.0:attrname-format:uri" \
isRequired="true" /><br> </eidas:RequestedAttributes><br> \
</saml2p:Extensions><br> \
.............<br></saml2p:AuthnRequest></font></span><br></pre></div><ul><li>Apart \
from the attributes, for indicating whether an authentication request is made by a \
private sector or public sector SP, the defined element <u><eidas:SPType> MUST \
be present</u> either in the <md:Extensions> element of SAML metadata or in the \
<saml2p:Extensions> element of a \
<saml2p:AuthnRequest>.</li></ul><div><div><br>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.<br><br><br>Currently in IS, <b>SAML \
Extensions processing </b>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.<br><ol><li><b>Register a set of SAML Extension \
Processors</b> - extensible mechanism where we can include any extension processing \
</li><li><b>eIDAS Extension Processor </b>- specifically handled the eIDAS \
extension</li><li><b>Invoke the processors when building the SAML \
assertion</b></li><ul><li>Consider that all the necessary attributes are configured \
as the SP requested claims</li></ul><ul><li>In the eIDAS processor, filtering out the \
requested attributes based on the "RequestedAttributes" elements in the \
authentication request<br></li></ul></ol></div></div></div></blockquote><div><br></div></div></div><div>+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.</div><div><br></div><div>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, <span \
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:nor \
mal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spac \
ing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wor \
d-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">and \
there are too many service providers to do this</span>. 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.</div><div><br></div><div>Regards,</div><div>Johann.</div><span><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div \
dir="ltr"><div><div><ol><ul><li></li></ul></ol></div><div><br>Really appreciate your \
suggestions and comments. <br><br><br>[1] <a \
href="https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/How+does+it+work+-+eIDAS+solution" \
target="_blank">https://ec.europa.eu/cefdigita<wbr>l/wiki/display/CEFDIGITAL/How+<wbr>does+it+work+-+eIDAS+solution</a><br>[2] \
<a href="https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/2016/12/16/eIDAS+Technical+Specifications+v.+1.1" \
target="_blank">https://ec.europa.eu/cefdigita<wbr>l/wiki/display/CEFDIGITAL/2016<wbr>/12/16/eIDAS+Technical+Specifi<wbr>cations+v.+1.1</a><br>[3] \
<a href="https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf" \
target="_blank">https://docs.oasis-open.org/se<wbr>curity/saml/v2.0/saml-core-2.0<wbr>-os.pdf</a><br><br></div>Thanks \
and Regards<span class="m_-4742169165812312967m_-3889877001601457205m_-2256109470209083340HOEnZb"><font \
color="#888888"><br clear="all"><div><div><br>-- <br><div \
class="m_-4742169165812312967m_-3889877001601457205m_-2256109470209083340m_-6269618223176958852gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><div><div dir="ltr"><span><font color="#888888"><div><span><font \
color="#888888"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><div style="font-size:12.8px"><div><font color="#000000">Indunil Upeksha \
Rathnayake<br></font></div><div><span \
style="color:rgb(153,153,153);font-size:12.8px">Software Engineer | WSO2 \
Inc</span><br></div><div><span style="color:rgb(153,153,153);font-size:12.8px">Email \
<font color="#888888"><a href="mailto:indunil@wso2.com" \
target="_blank">indunil@wso2.com</a> <br></font></span></div><div><span \
style="color:rgb(153,153,153);font-size:12.8px"><font color="#888888">Mobile <a \
href="tel:077%20218%202255" value="+94772182255" \
target="_blank">0772182255</a><br></font></span></div></div></div></div></div></div></ \
div></div></div></div></font></span></div></font></span></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div></font></span></div></div>
</blockquote></span></div><span class="m_-4742169165812312967HOEnZb"><font \
color="#888888"><br><br clear="all"><div><br></div>-- <br><div \
class="m_-4742169165812312967m_-3889877001601457205m_-2256109470209083340gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div><b><br></b></div><div><b>Johann<font \
color="#666666"> Dilantha Nallathamby</font></b><br></div><div><font \
color="#999999">Senior Lead Solutions Engineer</font></div><div><font \
color="#999999">WSO2, Inc.</font></div><div><font \
color="#999999">lean.enterprise.middleware</font></div><div \
style="color:rgb(136,136,136)"><br></div><div style="color:rgb(136,136,136)"><span \
style="color:rgb(153,153,153)">Mobile: </span><a value="+94773426635" \
style="color:rgb(153,153,153)"><i>+94 77 7776950</i></a></div><div><span \
style="color:rgb(153,153,153)">LinkedIn: </span><font color="#999999"><span \
style="font-size:12.8px"><i><a href="http://www.linkedin.com/in/johann-nallathamby" \
target="_blank">http://www.linkedin.<wbr>com/in/johann-nallathamby</a></i></span></font></div><div><span \
style="color:rgb(153,153,153)">Medium: </span><span \
style="color:rgb(153,153,153)"><i><a href="https://medium.com/@johann_nallathamby" \
target="_blank">https://medium.com/@jo<wbr>hann_nallathamby</a></i></span><span \
style="color:rgb(153,153,153)"><br></span></div><div><span \
style="color:rgb(153,153,153)">Twitter:</span><span style="color:rgb(153,153,153)"> \
</span><i style="color:rgb(153,153,153)">@dj_nallaa</i></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="m_-4742169165812312967gmail_signature" data-smartmail="gmail_signature"><div \
dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><span><font \
color="#888888">Thanks & Regards,</font></span></div><div dir="ltr"><span><font \
color="#888888">Dulanja Liyanage</font></span></div><div dir="ltr"><span><font \
color="#888888">Lead, Platform Security Team<br>WSO2 Inc. \
</font></span><br></div></div></div></div></div></div></div> </div></div>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic