Specifying prefixed namespace for SLO requests?

[Curtis Lacy]

After some further research into the requests being sent, it looks like the namespace is being defined properly in the original message, but aren’t being used by the parser that tries to interpret the decrypted NameID snippet.  This issue to be described by this comment I found in OpenSAML’s Decryptor:

        // Since Xerces currently seems not to handle parsing into a DocumentFragment
        // without a bit hackery, use this to simulate, so we can keep the API
        // the way it hopefully will look in the future. Obviously this only works for
        // input streams containing valid XML instances, not fragments.
I’m trying to run in a Tomcat8 container running under OpenJDK 1.7 - is it possible that I should be using a particular version of Xerces that is better behaved?  Just for reference, here’s my original request:


<samlp:LogoutRequest
    Destination="https://samwise.dev.lotame.com/idp/profile/SAML2/Redirect/SLO"
    ID="ONELOGIN_f66b05f5054fc178a60729d485c5a9d6022ce7b4"
    IssueInstant="2017-04-07T20:17:26Z" Version="2.0"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
        <saml:Issuer>{Actual Issuer here}</saml:Issuer>
        <saml:EncryptedID>
        <xenc:EncryptedData
            Type="http://www.w3.org/2001/04/xmlenc#Element"
            xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
            <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
            <dsig:KeyInfo xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
                <xenc:EncryptedKey>
                    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
                    <xenc:CipherData>
                        <xenc:CipherValue>dsVpBN1xCKk2e+vaFFSKrdk2z3RVJ8TkJ+1Lt5g/c7YM2M1rX9c7/YGCSMOXU7S6
SfCHns4EM+9yqsLBVWMlFwpTONc8YTNojl8T3F6tua8qLLu02RL/Zqf+TlN8vK+Z
zrTAl6c3LnzcdZtG/DIiG2GgcOX6VJCrBr39Lfs2zfg86cd3xj24skGWTMr0v4je
wh0t1/lZbLRePBWHXlr5kpzbGJsD+uoRkyoi8k817jN2ziZ7Xr2cBsDuJH2hJKU7
d/vvzcfPykdgUcjxJhpZu+gvbpPYA7VFNNaIC4w3TORRtA75DzK9NTasSuuat2rC
cneGPoZVS5Qa4sGu4QfN8w==</xenc:CipherValue>
                    </xenc:CipherData>
                </xenc:EncryptedKey>
            </dsig:KeyInfo>
            <xenc:CipherData>
                <xenc:CipherValue>urRsXcfYUKD/0VaeTZwNOHbKn5r1CtjIQUT/H1c0jSfoLLb43bPlvI/Kz4JcWALF
cHXeTyvNKMxhAKdS467O8iU9qrSQxeQTjnf515mX4s1z+L4yzxexhy0uBHnaAOWV
p87ZzSrJe4IOBqNvYdox4ISzQM6YjF1Itv58m5fc6c8=</xenc:CipherValue>
            </xenc:CipherData>
        </xenc:EncryptedData>
    </saml:EncryptedID>
        <samlp:SessionIndex>_ab0335715e51f8c0c3ba498f54bb223b</samlp:SessionIndex>
    </samlp:LogoutRequest>

and the decrypted NameID that the parser is balking at:

<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”>{Actual email address here}</saml:NameID>

Thanks for your help,

Curtis



> On Apr 6, 2017, at 2:52 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> Hi, I'm trying to set up a Shibboleth 3.3 IdP, and having trouble processing the
>> logout requests from a particular SP.  Once decrypted, the logout requests
>> look like this:
> 
> That's a decrypted NameID, not the whole request. When you embed namespace usage in encrypted content, it's a basic requirement that you have to ensure the prefix(es) get declared either within the content or in the original message.
> 
>> Is there a bean or property that I need to provide which defines this "saml"
>> prefix?
> 
> No, the message is simply broken, and the SP has a bug. I can't imagine that's Shibboleth but if it is you should certainly file it.
> 
> -- Scott
> 
> -- 
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


-- 
The information transmitted in this email is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material. Any review, retransmission, dissemination or 
other use of, or taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is prohibited. If you 
received this email in error, please contact the sender and permanently 
delete the email from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170410/b0aabd91/attachment-0001.html>