Shibboleth Developers

[Adam Lantos <>]

Here is the git repo url

git-clone https://repo.niif.hu/git/java-idp.git
https://repo.niif.hu/gitweb/gitweb.cgi?p=java-idp.git

IdP SVN head is in the master branch, see backchannel-slo branch for
the work-in-progress code. The branch is based on SVN r2866, but will
rebase later to 2.1.3 if it's released.


On Tue, Jul 14, 2009 at 12:50 PM, Adam 
Lantos<>
 wrote:
> 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
>>>
>>>
>>>
>>
>