Hi Frank,
If you get this same statement into a RADIUS response (you can easily hard-code it in the post-auth section), does it still segfault? If so, strip off the <samlp:Response>, as well as <saml:Issuer>, <ds:Signature>, and <samlp:Status>. Then try again. If that stops the segfault, this is still the same problem as what Vincent experienced.
Unfortunately I don't have access to my dev system otherwise I'd verify.
With Regards
Stefan
________________________________________
From: Frank Tamás [[log in to unmask]]
Sent: Tuesday, April 08, 2014 7:28 PM
To: [log in to unmask]
Subject: Re: debian moonshot-gss-eap segfault, AttributeQuery
Hi Stefan,
On 2014.04.08., at 16:36, Stefan Paetow <[log in to unmask]> wrote:
> Can you post the raw SAML that the AA releases?
this is the raw response:
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_6b1f628faa059cc8abfa023797ab6070e3fcadf5b5" Version="2.0" IssueInstant="2014-04-08T11:49:46Z" InResponseTo="_fa0afcf04466318a45565fde78e487c6">
<saml:Issuer>https://vo.eduid.hu/vo</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_6b1f628faa059cc8abfa023797ab6070e3fcadf5b5">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_ae951aafe23b567dee9aef78fac38628ebc23675b0" Version="2.0" IssueInstant="2014-04-08T11:49:46Z">
<saml:Issuer>https://vo.eduid.hu/vo</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_ae951aafe23b567dee9aef78fac38628ebc23675b0">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>...=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject>
<saml:NameID Format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">[log in to unmask]</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotBefore="2014-04-08T11:44:46Z" NotOnOrAfter="2014-04-08T11:54:46Z" InResponseTo="_fa0afcf04466318a45565fde78e487c6"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2014-04-08T11:44:46Z" NotOnOrAfter="2014-04-08T11:54:46Z">
<saml:AudienceRestriction>
<saml:Audience>https://ms-sp.aai.niif.hu/shibboleth</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AttributeStatement>
<saml:Attribute Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">urn:geant:niif.hu:yavom:moonshot-sp-ssh-szerver:ssh</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
> Is it a basic <saml:Assertion> that's being returned, or is it wrapped inside an <ecp:Response>?
> In July last year, Vincent Giersch from Uni Kent had a similar problem and once he pulled the Assertion statement from the ECP response, it all functioned ok. I don't know if this occurs here as well or not.
There is no ECP, and we cannot test it because simpleSAMLphp cannot speak ECP. Anyway I have tested some cases:
- there is no segfault, if the response contains empty AttributeStatement
- there is no segfault, if the same entilement value comes from SAML assertion comes from radius IdP
- there is no segfault, if the answer contains entitlement value, but the urn:oid:1.3.6.1.4.1.5923.1.1.1.7 attribute is not mapped by shibboleth sp
Thanks,
Tamas
>> -----Original Message-----
>>
>> Hello,
>>
>> I've set up our moonshot-enabled ssh server, but there is a scenario
>> where I get 'segmentation fault'. Our shibboleth SP would use the value
>> of eduPersonEntitlement attribute to make decision about releasing
>> local-login-user attribute to the ssh server. If the entitlement
>> attribute comes form the SAML assertion issued by the Radius IdP, it
>> works fine, but if shibboleth SP asks an AttributeAuthority about the
>> user's entitlement with AttributeQuery, and the answer contains at
>> least one value, it crashes with segfault.
[...]
>>
>> Has anybody seen this bug yet?
>>
>> cheers,
>> --
>> Tamas
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
|