Base64 encode SAML Response problems?

Brent Putman putmanb at georgetown.edu
Mon Feb 18 17:41:27 EST 2019


On 2/17/19 9:13 PM, o haya wrote:
>
> What I have been able to do thus far is implement a Java app that can
> produce a SAML response message that includes an signed assertion and
> that looks like it matches some SAML response messages that I have
> captured from previous testing with OAM federation. 


Well, if you're implementing an Identity Provider, as it sounds like
you're doing, there's no substitute for reading the SAML 2
specification.  Otherwise you're probably going to make mistakes that
you don't even know you're making.  OpenSAML is just a toolkit library,
it doesn't auto-magically do everything you need to know.


>
>
> ...
>         Base64.Encoder encoder =
> Base64.getUrlEncoder();                     

The correct Base64 variant to use with SAML is not that one, which is
the newer URL- and filename- safe version (used in JOSE, JWT and
friends).  SAML specifies the use of just the old "standard" Base64
encoding.  (Which you may find in the SAML specs...)  Read on, however.



>         String str = encoder.encodeToString(samlResponse.getBytes());  
>         String str2 = "SAMLResponse=" + str +
> "&RelayState=https%3A%2F%2Fsandboxdtm01.xxx.dev%3A38443%2Ftest.html";
>        
> System.out.println("\n\n========================================\nBASE64-Encoded
> string:\n");
>         System.out.println(str2);
>        
> System.out.println("\n============================================\n");
>
> ....
>        
> The resulting 'str2' value looks like (following is a snippet of an
> example):
>
> SAMLResponse=PD94.....cDpSZXNwb25zZT4=&RelayState=https%3A%2F%2Fsandboxdtm01.gxaws.dev%3A38443%2Ftest.html
>
> and I send that 'str2' value as the content body in a POST to the OAM
> SP endpoint, which results in the 'system error'.


If you're implementing a standard SAML 2 IdP doing the Browser SSO
Profile, that's not correct.  SAML 2 protocol messages are conveyed by
what are called bindings.  What you are doing above doesn't conform to
any standard SAML 2 binding.  From your description it sounds like you
are probably trying to implement the SAML 2 HTTP POST binding, but
that's not at all how you do it.  See the SAML 2 Bindings specification.



>
>
> Also, part of the reason I am asking the above (besides the error
> stacktraces mentioning Base64) is that, from the logging of the
> "good" captures that I did with OAM previously, it looks like the
> SAMLResponse that is being sent in the "good" tests end with TWO
> equal signs ('==') whereas the Base64 strings I am seeing from my
> code seem to have only one equal ('=') at the end, which is making me
> wondering if I should be doing different for the Base64 encoding?
>

That's not really significant.  The number of '=' padding chars on the
end of Base64-encoded data is determined indirectly by the number of
bytes that were encoded.  So it will vary depending on the actual
data.  That's not a problem.

You really ought to go back and consult the specs so you fundamentally
understand the requirements of SAML, including the profile you're
trying to implement.  Trying to "reverse engineer" this by looking at
wire traces, etc is likely to lead you astray, and lead to at best an
incorrect implementation, and at worst to an insecure one.  This is
security middleware, after all.

You might also consider why you're trying to write a SAML IdP in the
first place, given that there are a number of good implementations
already available, including free open-source ones like Shibboleth (our
project) and SimpleSAMLphp, as well as others.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190218/1d8f6faa/attachment.html>


More information about the dev mailing list