Base64 encode SAML Response problems?

[o haya]

 Hi,
It's hard to explain "Why?" I am doing what I am trying to do, but your guesses were somewhat close.  I do understand what you are saying, and I had suggested that if "they" wanted to do this, they should just go ahead and help our partner stand up an IDP on their end instead, but I was over-ridden and so, naturally, I got stuck with it :)...
You are also correct that, protocol- (or binding-) wise, what I am trying to get working is something that acts like the HTTP POST binding, but that is compatible with our OAM SP-side, at least to the point of getting the SP to process the SAML Response that we send to it.  

To be frank, I am not 100% sure that this is going to be possible yet, because I think that there is other "stuff" (headers, cookies, etc.) that the Oracle SP requires, but, for now, I am just trying to get the SP to not throw a fit when it sees the message that I am sending to it (and I'm not even 100% sure if THAT is possible, yet).
Thanks for your comments.
Jim







    On Monday, February 18, 2019, 5:41:46 PM EST, Brent Putman <putmanb at georgetown.edu> wrote:  
 
  

 
 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.
 

 
 

 
 

 
 -- 
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190219/5deee866/attachment-0001.html>