WebSeal

Question

We need to hide Groupshare application server behind transparent proxy &ndash; WebSeal. WebSeal provides another authentication that is very important for us before it sends request to backend server. Unfortunately it seems that Groupshare application server needs some http header, but this is lost when going through WebSeal and user authentication fails on /api/management/v2/users. I have not found anything helpful in Knowledge Base. I would like to ask whether it is possible to use some configuration that would provide running application server behind WebSeal. If you have some experience, if it is possible and how much would the support of supplier cost in this case. 
 About WebSeal: https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.5/com.ibm.isam.doc/wrp_config/concept/con_ws_authe.html

Zoltan Balazs · Answer

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"

Raphael Batel · Answer

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.

Zoltan Balazs · Answer

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.

Raphael Batel · Answer

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):// /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 /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 /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.

Trados GroupShare > 1. General

WebSeal

Top Replies