Hi Stefan,
On 2014.04.08., at 22:04, Stefan Paetow <[log in to unmask]> wrote:
> 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.
I have checked it, and it worked fine without segfault.
I think the problem lies elsewhere. I have the following resolver config:
<AttributeResolver type="Chaining">
<AttributeResolver type="Query"/>
<AttributeResolver type="Transform" source="local-login-user">
<Regex match="^([^@]*)@(.+)$">$2</Regex>
</AttributeResolver>
<AttributeResolver type="SimpleAggregation" attributeId="eppn" format="urn:oid:1.3.6.1.4.1.5923.1.1.1.6">
<Entity>https://vo.eduid.hu/vo</Entity>
<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" FriendlyName="entitlement"/>
</AttributeResolver>
</AttributeResolver>
It seems that the crashes occur if an AttributeResolver other than "Query" resolves any attribute, because if I change the "Transform" above to resolve to another attribute ('dest' parameter), it also crashes sshd. Similarly, if "SimpleAggregation" resolves no attributes, it doesn't crash.
If it would help you with debugging, I can get the AA above to provide your SP a SAML response. (Contact me off-list about the details.)
thanks,
Tamas
>
> 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
|