Problem requesting $metadata with SAML2 configured.

[former_member186439]

We have configured a NetWeaver Gateway to use Microsoft Active Directory Federation Server (ADFS) as an Identity Provider and all in all everything is working great with one exception.  We are trying to use SAPUI5 (JavaScript) to access OData services on the Gateway and we are having issues with the calls for $metadata.

After staring at Fiddler for many hours, I think I know what might be happening.

Whenever a SAPUI5 web page makes a call to an OData service, it actually calls the Gateway server a number times.

1) It requests the metadata for the service.  
2) It calls the service asking for a count of the results.
3) It call the service and retrieves the data.

The problem is with the first call, $metadata.  If this is the first call of the session (the one forcing authentication), the call hangs.  If it's not the first call of the session (the session is already authenticated), everything works.   My working theory is that requests for $metadata don't require authentication (anonymous authentication).  However, the federation driven redirections are confusing things and causing the request to fail.

The simple work around for this problem is to always be already authenticated before requesting $metadata.  A single ‘trip’ to ADFS sets the SAML tokens that are good for the rest of the browsing session.  If the session is already authenticated, the redirection on the $metadata request doesn’t happen and everything works.   With the NetWeaver Business Client, the authentication occurs as part of the client startup.  That’s why we’ve never seen this issue in any of our testing using NWBC.  For other ‘outside-in’ clients (e.g. Internet Explorer) the JavaScript programmer needs to ensure that JavaScript code has ‘initialized’ the connection (force authentication to occur) before the $metadata call occurs.  He can do this by doing an HTTP GET against some bogus content on the SAP server.

My guess is that most SAP clients never run into this issue because they store their HTML pages on the same server as their web services.  The act of pulling up their HTML pages is in-effect ‘initializing’ their connections.

Has anyone else encountered this issue?  Is there a more elegant solution than my work around? 

[kammaje_cis · Accepted solution]

I do not think that your $metadata is without authentication. Rather I see this as a generic problem in accessing gateway first without authenticated cookies. Since metadata is always the first call with odatamodel, it is what which is failing.

If you want to confirm that $metadata is without authentication, I would suggest you to test in a fresh browser window , by directly entering metadata URL.

I expect this to be some SSO related config issue.

[former_member186439 · Accepted solution]

Krishna, you are right.  The $metadata call is authenticated.  I now have a different theory of the problem.

After the Identity Provided, in this case ADFS, authenticates the session, it 'returns' some content that includes a hidded form and some JavaScript that is automatically invoked.  The JavaScript posts this hidden form to the SAP Service Provider URL so that SAP can convert the SAML data contained in the form to a SAP logon.  I now think that in the context of a web service call, there is no way for this JavaScript to execute.  I'm beginning to wonder if the SAML2 Web Single Signon Scenario is even appropriate for OData calls.     

[kammaje_cis · Accepted solution]

I am not an expert on SSO, but I can confirm that using ADFS with SAML2 and Gateway is a common scenaro.

https://help.sap.com/saphelp_nw74/helpdata/en/2f/82215150e92414e10000000a44176d/content.htm?frameset...

[former_member186439 · Accepted solution]

Krishna's link led me to a page with this statement:

"When the user accesses Gateway applications using client browsers, SAML 2.0 authentication must preserve the original HTTP GET method. Thus SAML 2.0 Artifact binding must be used instead of POST."

Everything we have done to date is using Post Binding.  I guess that may explain why the $metadata calls are hanging - the system expects a GET request and does not know what to do with a POST request.

Does anyone know whether this requirement to use SAML 2.0 Artifact Binding still applies if you use SAML Bearer Tokens and OAuth?