Shibboleth Developers

[Adam Lantos <>]

Hello,

Yesterday my IdP was able to issue back-channel logout requests to the
session participant SPs on receiving a logout request from one session
participant.

I have lots of questions and some ideas to comment:

1, LogoutRequest processing is done like in AttributeQueryHandler,
most of the code is copied over. However, it might be bad idea to
duplicate code like populateXXXInformation or selectEndpoint methods.

2, In order to implement SOAP binding for SAML requests, I use
commons-httpclient, which is included in OpenSAML.

 - HTTP connection using SSL with certificate validation from
metadata. Client authentication will also be required, but since SP is
behind a web server, it cannot force transport authentication, so
request signing is a must.
 - Adapting HTTP client connection to HTTPOutTransport.

3, OpenSAML HTTPSOAP11Encoder treats the OutTransport as
HTTPOutTransport, which is fine considering HTTP is required for
SOAP/HTTP. But the HTTPOutTransport interface looks like it was
developed for HTTP responses (setStatusCode(), sendRedirect()). So
wrapping the HTTP client connection introduces further questions. For
now, I have lots of UnsupportedOperationExceptions in the code and the
only implemented methods are setHeader, setCharacterEncoding,
getOutgoingStream, isConfidential, isIntegrityProtected,
getHTTPMethod, and getVersion. With these codes in place,
HTTPSOAP11Encoder can bind SAML LogoutRequest to the SOAP request (and
SP consumes that).

4, NameID resolution is an issue. Now I use resolveAttributes() and
buildNameID() methods in AbstractSAML2ProfileHandler. For this, I had
to rewrite the _inbound_ message issuer to be the SP entity ID for
which I want to generate the NameID:

    requestContext.setInboundMessageIssuer(spEntityID);
    resolveAttributes(requestContext);
    NameID nameId = buildNameId(requestContext);

This problem can be resolved easily by placing NameID and SessionIndex
in Session/ServiceInformation, as I wrote in one of my previous
letters.

5, Threading issues. What happens if one profile thread is blocking on
SOAP requests? We need all LogoutRequest processing code to be
reentrant.


I'll post my repo url shortly, you can have a quick look on my WIP
code if you want.


cheers,
 Adam



On Sun, Jul 12, 2009 at 11:32 PM, Adam 
Lantos<>
 wrote:
> My first intent is to get used to opensaml / openws, so the code is
> more like a big bowl of spaghetti now. Most of the code will be thrown
> out, as first tries always are.
>
> Unfortunately the IdP does not send any requests by itself, so I
> didn't find security and trust bits for SOAP/SSL clients and SAML
> requests. For now, I'll also omit the policy/profile configuration for
> logout requests (signing, nameid encryption), but it'll be included
> later of course.
>
>
>
> On Sun, Jul 12, 2009 at 11:17 PM, Scott 
> Cantor<>
>  wrote:
>> Adam Lantos wrote on 2009-07-12:
>>> I'm struggling a bit with commons-httpclient now, but after I'll
>>> figure out how to properly use SSL client certificate authentication
>>> and certificate check against SP metadata - I have the bits in place
>>> now, it should work soon -, I'll post more details about back-channel
>>> logout requests issued by the IdP. I expect to get my proof-of-concept
>>> version working in the next few days.
>>
>> It's imperative that any code involving trust be using the same security 
>> code from the rest of the stack. It doesn't matter for your purposes, but 
>> there's no way we would ever even look at code that was one-offing that 
>> stuff. It's too hard to get right and we cannot afford the chance of 
>> introducing inconsistencies. All runtime checks must be using the same 
>> trust engine code throughout the system.
>>
>> -- Scott
>>
>>
>>
>