Hi Eugen, 

Groupshare backend services hosting Rest API endpoints require the Authorization header to be set. Most of the times this is the only required header. If it's missing authorization will fail. Can you detail maybe what headers you see going through WebSeal and what you consider as missing?

There is no setting that you can configure for running behind a proxy, as Groupshare doesn't need to know it's behind a proxy. This needs to be configured from the proxy, either to not remove specific headers or to re-add it. 

Maybe this section in WebSeal documentation can help out: https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.6/com.ibm.isam.doc/wrp_config/concept/con_http_transforms.html. As noted there "WebSEAL administrators can configure the following modifications. You can apply these transformations to HTTP requests and HTTP responses (except where otherwise noted):

• Add a header
• Remove a header
• Modify an existing header"

Hi Zoli,

thanks for the explanation. We try this with our new server.

Another question - In our company, it is forbidden to use basic http authentication. I would like to ask, whether it is possible in Groupshare 2020 SR1 web interface to use SAML tokens? We would like to use own security provider based on SAML 2.0. What is TokenExchange interface able to use except of Okta provider, are there any guides?

Hi Eugen,

We have succesfully tested different SSO providers using SAML, like Okta, ADFS and Auth0.  There are a couple of attributes that needs to be present in the SAML response so that Groupshare is able to locate the user. There is a special user type in Groupshare (IDP user) that is used for SSO users. In this case user credentials are not stored with Groupshare, but the user still needs to be provisioned - so that Groupshare roles and permission can be set. 

The attributes that needs to be present in the SAML response are: "user.firstName", "user.lastName", "user.email". These are mandatory and must use these exact attribute names. 
An example:

We have some guidelines written for Okta and Auth0 that you could follow - some of the information might be outdated (as Okta and Auth0 user interface changes from time to time). 

I can send it to you in an email, just le me know.

Regards. 

Hi Zoli,

perfect, can you send it please to eugen.drgon@skoda-auto.cz.

With best regards

Eugen

Hello, has anybody tried to run Groupshare 2020 behind WebSeal? Everything works, except of Reporting module. Dashboard screen ends with 500 error.  IIS log shows /api/authentication/token/reportingSignIn with 500 error.

If you are on GroupShare 2020 CU03, there should be additional error details logged in the application service logs.

In CU04, this problematic "reportingSignIn" will actually be removed.

The general idea/problem is as follows:

When a user logs into the website:

1. The http request "http(s)://<servername>/api/authentication/token/reportingSignIn" is sent as follows:

Browser -- Network (including proxies, if any) --> GS Web Server (IIS) --> GS Application server (Application Service)

This request contains "requestOrigin" in form data, which is generally set to the URL via which the user accesses the GroupShare website.

2. Then the application service (on the application server) sends a further http request to

<requestOrigin>/Reporting/rdTemplate/rdGetSecureKey.aspx

This request is supposed to reach whe GS Web Server (IIS).

If it fails, the original reportingSignIn will be failed with a 500 status code.

So, until you upgrade to 2020 CU04, you would have to ensure that the request <requestOrigin>/Reporting/rdTemplate/rdGetSecureKey.aspx originating from the GS Application server (Application Service) can successfully reach the web server.

Possible problem that can occur or I could image:

A) The server name in requestOrigin cannot be resolved on the application server or is resolved to the wrong machine

B) If https is used: ssl secure channel cannot be established (depends on your network setup)

C) (never saw this, but possible your case) the request from application server to web server goes via proxy and proxy requires authentication. Probably the application service does not know how to authenticate with the proxy.

In any case, first step would be to check Application service logs ("C:\ProgramData\SDL\Service\Logs\Sdl.Application.log") whether anything is logged at the time of the failed request.

Thank you for your comprehensive answer. It perfectly complements everything what I found out by analyzing our logs, but communication from application server to web server is quite problematic and unexpected and that is the cause why it fails.

The only way is to use proxy, so I would like to ask how to set proxy for Groupshare to use it correctly for this situation?

Maybe better solution is to avoid this "reportingSignIn" and "rdGetSecureKey" in such a way at all, so I would like to ask when CU4 will be ready for download?

And one more question - in CU4, is there any other communication from application server to web server that is initiated by application server except "rdGetSecureKey"? 

Hello!
Sorry for the late answer, it seems the forum does not want to send me notifications about responses!

"The only way is to use proxy, so I would like to ask how to set proxy for Groupshare to use it correctly for this situation?":

- I dont have any specific instructions at hand (and instructions tend to not cover all special cases anyway), but if proxy authentication is the problem, you may want to check out https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/network/defaultproxy-element-network-settings and apply this to "C:\Program Files (x86)\SDL\SDL Server\Application\ApplicationService.exe.config" (and ExecutionService.exe.config; this is a feature provided by the .NET Framework, so public documentation will be more extensive and accurate than what SDL can tell you.

This of course assumes that proxy authentication is the problem. To confirm, if you have CU03, you may want to check the logs to confirm this, in a previous version you might have to run a network trace (for outgoing requests from SDL Application Service) to confirm.

"so I would like to ask when CU4 will be ready for download?"

- I dont have official information regarding that, but should be "soon".

" is there any other communication from application server to web server that is initiated by application server except "rdGetSecureKey"? "

- Yes, especially when creating projects on the website or via the RestAPI (but also for a minor number of other features, e.g. viewing project settings and project templates on the website), requests are sent from the application server to the URL of resources used in the project (TMs). The URL is generally referring to the external server address. Unfortunately, I do not have a complete list of possible requests for this.