SAML artifact 1.1 format

[Former Member]

Hi,

We have an AS java (netweaver 7.01 SPS 6) where we have a webapplication. Endusers must log on to an external identity provider, receive a saml artifact (saml 1.1) and should be authenticated on our java stack.

However this only works intermittently. It appears that saml artifacts with a "+" are being decode wrongly by the AS java.

If I call the external idp and it generates a samlart with a "" in it e.g. it AAFcv9YPoHqOW2jkAfvMPVIg7zE5lj4SpprandomstringuHDQYAAAA

I get the following exception in the defaulttrace, the decode method in the SAP standard java class com.sap.security.core.server.util0.Base64 is called to decode the saml artifact, but it doesn't pass the "+" sign.

Caused by: java.text.ParseException: Base64 input data were terminated out-of-sync and without equals-signInput String:AAFcv9YPoHqOW2jkAfvMPVIg7zE5lj4 SpprandomstringuHDQYAAAA String Length:56

at com.sap.security.core.server.util0.Base64.decode(Base64.java:478)

The saml artifact was received correctly though by the http listener on the AS java, I see the coreect saml artifact in the httpaccess trace:

1.2010 19:39:45.582 ALL [Nov 3, 2010 7:30:23 PM ] - 172.17.202.38 : GET /webapp/redirect.jsp?SAMLart=AAFcv9YPoHqOW2jkAfvMPVIg7zE5lj4+SpprandomstringuHDQYAAAA HTTP/1.0 302 1768 d[12] c[1298944]

Do you think this is a SAP bug or should a SAML artifact not contain a "+" sign?

Thanks in advance!

Best Regards,

Steven

[mvoros]

Hi,

to me it looks like your application are using different variant of Base64. SAP is expecting Base64 which does not use +. There are variants where different character is used. Hard to say which one is wrong. You need to read SAML spec. Check wikipedia for more info as well.

Cheers

Correct my statement.

Edited by: Martin Voros on Nov 4, 2010 6:33 AM

[Former Member]

Hi,

Thanks a lot for your message. I checked further the SAP code that is giving problems (com.sap.security.core.server.util0.Base64.java), and SAP itself is using the following conversion table in it, which does include a "+" sign.

private static final char[] _conversion =

{'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z','a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z','0','1','2','3','4','5','6','7','8','9','+','/' };

If I change the "+" sign in the artifact by any other base64 allowed character, the SAP system does decode it correctly and even requests an assertion to the idp (which of course subsequently fails as the idp did not create this particular artifact).

e.g. the following artifact, if generated by the idp, would work:

AAFcv9YPoHqOW2jkAfvMPVIg7zE5lj4ASpprandomstringuHDQYAAAA

Best Regards,

Steven

[mvoros]

That's weird. So it looks like it should work but it doesn't. Have you raised OSS note? Or have you tried to write a simple Java program which reuses SAP class and debug it why it fails?

Cheers

[Former Member]

Hi,

Thanks, SAP came back to me with the following:

"this is a known issue and here is the explanation:

As you know the base64 standard includes all latin small and capital

letters, digits 0-9, + and / characters:

http://en.wikipedia.org/wiki/Base64

As + and / are special characters, when transmitted over the web as partof an URL parameter they should be encoded. If they are not when the

server SAML module obtains the parameter from the request the web

container provides that param, but it furst decodes it itself. So it is

as if the param is decoded twice instead of once. This web container

behaviour (to provide the parameters in their decoded) form is correct.

What should be fixed is the URL providing the parameter by encoding the

paramter before sending it to the server.(e.g. if using utf-8, then +

would become %2B and / would become %2F; of courese whether utf-8 would

be used depends on the caracter set used in the request to SAP server

from IdP). So this is a matter of configuration of the IdP which

constructs the URL. "

The idp had to use url encodong for the "+" and "/" character. This is resolved now.

Best Regards,

Steven