The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Dubravko Voncina <dubravko.voncina AT srce.hr>]

Yes, I know this is a somewhat dirty solution, but that's because we're 
performing a lot of protocol and user data adaptation at SP proxy.
Also, there are many differently configured SAML IdPs in eduGAIN so it's 
practically impossible to configure SP proxy completely "by the book" if we 
want authentication to work for most users.
Currently, if your IdP doesn't provide attribute 
"urn:oid:1.3.6.1.4.1.5923.1.1.1.10", SP proxy checks if IdP provided 
persistent NameID in the AuthNResponse subject and forwards this value as 
your unique ID attribute to application (we have to translate subject NameID 
to attribute because application only knows how to work with certain 
attributes).
Thank you very much for your assistance, I hope that authentication to 
eduroam CAT and monitoring services will now work for the majority of 
"eduGAIN enabled" users.

Dubravko Voncina
Middleware and Data Services Department
University of Zagreb, University Computing Centre, www.srce.unizg.hr
dubravko.voncina AT srce.hr,
 tel: +385 98 219273, fax: +385 1 6165559




> On 21 Feb 2017, at 18:29, Zenon Mousmoulas 
> <zmousm AT noc.grnet.gr>
>  wrote:
> 
> Hi,
> 
> On 2017-02-21 19:04, Dubravko Voncina wrote:
>>> On 21 Feb 2017, at 17:22, Zenon Mousmoulas 
>>> <zmousm AT noc.grnet.gr>
>>>  wrote:
>>> ...
>>> What I suggested before was to set (in SSPHP settings) saml:NameIDPolicy 
>>> to null (not persistent)...
>> Actually, I thought this saml:NameIDPolicy => null was a sort of typo
>> in your mail. My bad :-(
> 
> Sorry for that.
> 
>> Ok, let's try that. Please try authenticating again, maybe now things
>> will finally work as expected.
>>> I also noticed the first SAML request[1], which also carries such a 
>>> NameIDPolicy. I'm not sure how the above would work with your backend SP 
>>> in the proxy scheme, but I would guess you might also need to apply the 
>>> same saml:NameIDPolicy there.
>> I must admit I have no idea what will happen until you try. I've
>> tested with Croatian and Polish IdPs and from what I can see,
>> everything works fine with those Identity Providers.
> 
> I just did, tl;dr: it seems to work fine :)
> 
> The 1st request (from 
> https://cat.eduroam.org/localhost/module.php/saml/sp/metadata.php/default-sp
>  to https://monitor.eduroam.org/sp/saml2/idp/SSOService.php) does carry a 
> NameIDPolicy[@Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"],
>  just like before.
> 
> The 2nd request (from 
> https://monitor.eduroam.org/sp/module.php/saml/sp/metadata.php/default-sp 
> to https://idp.admin.grnet.gr/idp/profile/SAML2/POST/SSO) does not carry a 
> NameIDPolicy now.
> 
> Hence my IdP responds with such a subject:
> 
> <saml2:Subject>
>  <saml2:NameID
>      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
>      NameQualifier="https://idp.admin.grnet.gr/idp/shibboleth";
>      
> SPNameQualifier="https://monitor.eduroam.org/sp/module.php/saml/sp/metadata.php/default-sp";
>  xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">[...]</saml2:NameID>
>  <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
>    [...]
>  </saml2:SubjectConfirmation>
> </saml2:Subject>
> 
> In the proxied response back to cat.eduroam.org (which is unencrypted) I 
> can see a different subject (with a transient NameID):
> 
> <saml:Subject>
>  <saml:NameID 
> SPNameQualifier="https://cat.eduroam.org/localhost/module.php/saml/sp/metadata.php/default-sp";
>               Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>               >[...]</saml:NameID>
>  <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
>    [...]
>  </saml:SubjectConfirmation>
> </saml:Subject>
> 
> But I can also see the original persistent NameID carried over as an 
> attribute:
> 
> <saml:AttributeValue 
> xsi:type="xs:string">eduPersonTargetedID:[...]!https://idp.admin.grnet.gr/idp/shibboleth</saml:AttributeValue>
> 
> Despite this last thing, CAT is presumably happy with the identifier it has 
> received, as it shows my data :)
> 
> I would still suggest that you consider not translating the subject to an 
> attribute, but I understand there may be other complications.
> 
> In any case, thanks for fixing this after all!
> 
> Regards,
> Z.