RE: [Shib-Users] Client-application authentication

[Daniele Bertolotti]

Dear all,
so we finally decided to Shibbolize our application simulating a browser behaviour. Considering the protocol flow presented here in the expert demo on the Switch website (http://switch.ch/aai/demo/2/expert.html) we successfully reached step 8 and the IDP is now replying to our last http request with the HTML page including the SAML assertion coded using base64. Following the flow, we parsed this last html webpage and generated a new request, simulating the auto-submit-post-form action: this implies sending to the SP a post request including the RelayState, the SAMLResponse and adding the _shibstate_ cookie to the request.
The response to this request though is an error from the SP that says: "Unable to decode Base64 in POST binding message". I couldn't find more about it in the SP log files. Of course when we use Shibboleth through the browser everything works fine, so I'm assuming that something goes wrong either when it comes to parse the SAMLResponse attribute from the IDP response and replicate it in the request for the SP or when we break the auto-submit-post-form action. I also thought that we might be breaking some kind of encryption, but we couldn't figure out which one exactly (I assume the SAMLResponse is encrypted with the IDP certificate/publickey, so there shouldn't be any problem with that since it's not related with the actual http flow...am i missing something here?).
Could anyone out there give us a hint about what's going on and how could we fix this? Let me know if you need more details about what we have done so far.
I should probably post this also to the dev mailing list.

Thank you in advance!
Daniele

>>> "Scott Cantor" <cant...@osu.edu> 03/03/09 3:12 PM >>>
Daniele Bertolotti wrote on 2009-03-03:
> I'm designing a system in which a client-application (no browser and
> no human intervention) has to access a resource (a web application or
> a web service) protected by Shibboleth.

The current SAML-flavored solution for that use case is the SAML 2 ECP
profile, which the SP supports but the IdP does not (yet). The delegation
work involving uPortal will include adding some support for this, but there
are still issues involving the client authentication that are ill-defined,
and our focus is on service authentication to the IdP via client
certificate, rather than client authentication.

> On the web I've found this
> page http://www.thomas-bayer.com/shibboleth-web-services-sso-en.htm
> showing how this could be achieved.

I'm not a believer in using browser profiles to solve a non-browser problem,
but ultimately the client is what drives the solution at the end of the day.

-- Scott

[Scott Cantor]

Daniele Bertolotti wrote on 2009-03-18:
> The response to this request though
> is an error from the SP that says: "Unable to decode Base64 in POST
> binding message".

That's the error, I don't know what else you want to know. You've corrupted
the SAMLResponse parameter.

> I couldn't find more about it in the SP log files.

Because there's nothing else to say about it.

> Of course when we use Shibboleth through the browser everything works
fine,
> so I'm assuming that something goes wrong either when it comes to parse
> the SAMLResponse attribute from the IDP response and replicate it in the
> request for the SP or when we break the auto-submit-post-form action.

Well, yes.

> I also thought that we might be breaking some kind of encryption,

No.

-- Scott

[EC_Johnson2000]

*Answer*: In my case, I was able to resolve this by correctly URL Encoding
the HTTP Body of the request I sent back to the SP after authenticating with
the IdP. Specifically, the base64 encoded SAMLResponse contains '+'
characters which get turned into spaces ' ' unless they are encoded as
'%2B'.

More details:

I'm developing a similar application and encountered a similar error to
Daniele's. I noticed there's not a lot in the way of useful posts on the
Google machine so here's what I did to resolve it.

Daniele Bertolotti wrote:
>
> The response to this request though is an error from the SP that says:
> "Unable to decode Base64 in POST binding message". I couldn't find more
> about it in the SP log files.

My app (though this is a cross-platform issue):
- Is a Objective-C/Cocoa app for the iPhone that needs to authenticate and
download files from a Shibboleth protected Apache server.

Where I got:
<UL>
<LI>Collect user name and password
<LI>Submit credentials to the target URL with HTTP Basic authentication
<LI>Receive the binding template for the authenticated user from the IdP (an
HTML form whose action is the SP and containing the SAMLResponse hidden
parameter
<LI>Submit a second HTTP request to the binding template's action with the
two hidden parameters and the cookie.
</UL>

My error:
- The response to the second HTTP request simply says "Unable to decode

Base64 in POST binding message"

My resolution:
- In assembling the second HTTP request I needed to correctly URL Encode the
HTTP body. Primarily this was for the "+" signs which are used by the
base64 encoding. They needed to be converted to "%2B".

Here's the code snippet I use to prepare the second HTTP Request, which
submits the two parameters provided by the IdP to the SP:

<code>
// Note that I parse the three parameters to this function from the HTML
returned by the IdP after the first exchange. This function prepares an
HTTP Request and submits it asynchronously to my custom delegate, which is
out of scope of this posting
-(void)authReturnTo:(NSURL *)url WithRelay:(NSString *)relayState
AndSAML:(NSString *)samlResponse {

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url
cachePolicy:NSURLRequestReloadIgnoringCacheData
timeoutInterval:12.0];
[request setHTTPMethod:@"POST"];

NSString *preBody = [[NSString alloc] initWithString:@"RelayState="];
preBody = [preBody stringByAppendingString:relayState];
preBody = [preBody stringByAppendingString:@"&"];
preBody = [preBody stringByAppendingString:@"SAMLResponse="];
preBody = [preBody stringByAppendingString:samlResponse];

/* THIS STATEMENT CORRECTED MY 'Unable to decode Base64 in POST binding
message' ERROR
There seems to be a shortage of URL Encoding features in Cocoa -
Fortunately the '+' is the
only character base64 has to worry about it seems */
NSString *httpBody = [preBody stringByReplacingOccurrencesOfString:@"+"
withString:@"%2B"];
NSData *httpBodyData = [httpBody dataUsingEncoding:NSUTF8StringEncoding];

NSString *httpContentLength = [NSString stringWithFormat:@"%d",
[httpBodyData length]];

[request setHTTPMethod:@"POST"];
[request setValue:httpContentLength forHTTPHeaderField:@"Content-Length"];
[request setValue:@"application/x-www-form-urlencoded"
forHTTPHeaderField:@"Content-Type"];

[request setHTTPBody:httpBodyData];

AuthenticationRedirectDelegate *delegate = [[AuthenticationRedirectDelegate
alloc] init];
[delegate setTv:tv];

[[NSURLConnection alloc] initWithRequest:request delegate:delegate];
}
</code>

Hope this helps!

--
View this message in context: http://n2.nabble.com/RE-Client-application-authentication-tp2497844p4713047.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.