Bug 1067413
| Summary: | Authentication failure while attempting to access remote S-RAMP repository | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Fuse Service Works 6 | Reporter: | Stefan Bunciak <sbunciak> | ||||||
| Component: | DT Governance | Assignee: | Thomas Heute <theute> | ||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Matej Melko <mmelko> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 6.0.0 GA | CC: | eric.wittmann, ganandan, soa-p-jira | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | FUTURE | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2025-02-10 03:35:08 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Stefan Bunciak
2014-02-20 12:29:21 UTC
Created attachment 865489 [details]
Configuration of dtgov
Created attachment 865490 [details]
Configuration of dtgov-ui
Note that I configured both servers to use the same passwords, and that the servers were able to 'see' each other (firewalls down, etc.) I was also able to upload ontologies from server A to server B using s-ramp cli. You need to make sure that the same overlord keystore is being used by both A and B. The keystore contains encryption keys used to sign and verify the authentication token used when dtgov talks to s-ramp. Just take the keystore file from A and copy it to B, or else put the keystore somewhere that both servers can access (e.g. an NFS mount). Note regarding the CLI comment: the CLI connects directly to an s-ramp repository and uses BASIC authentication... so that's a different animal from the UI (which uses digitally signed bearer tokens to authenticate). Copying overlord-saml.keystore from 'A' to 'B' did not fix this completely. I was now able to create new deployment, inspect its content, etc. *but* got another Auth failure from dtgov/jbpm integration. This exception was raised in server log when I tried to navigate to 'Task Inbox': 1:29:45,494 ERROR [org.overlord.dtgov.jbpm.util.KieSrampUtil] (http-localhost.localdomain/127.0.0.1:8080-4) Authentication failure while attempting to access the S-RAMP repository.: org.overlord.sramp.atom.err.SrampAtomException: Authentication failure while attempting to access the S-RAMP repository. at org.overlord.sramp.atom.client.ClientRequest.handlePotentialServerError(ClientRequest.java:192) [s-ramp-atom-0.3.1.Final-redhat-7.jar:0.3.1.Final-redhat-7] at org.overlord.sramp.atom.client.ClientRequest.post(ClientRequest.java:96) [s-ramp-atom-0.3.1.Final-redhat-7.jar:0.3.1.Final-redhat-7] at org.jboss.resteasy.client.ClientRequest.post(ClientRequest.java:571) [resteasy-jaxrs-2.3.6.Final-redhat-1.jar:2.3.6.Final-redhat-1] at org.overlord.sramp.atom.client.ClientRequest.post(ClientRequest.java:84) [s-ramp-atom-0.3.1.Final-redhat-7.jar:0.3.1.Final-redhat-7] at org.overlord.sramp.client.SrampAtomApiClient.query(SrampAtomApiClient.java:689) [s-ramp-client-0.3.1.Final-redhat-7.jar:0.3.1.Final-redhat-7] at org.overlord.sramp.client.SrampAtomApiClient.query(SrampAtomApiClient.java:644) [s-ramp-client-0.3.1.Final-redhat-7.jar:0.3.1.Final-redhat-7] at org.overlord.sramp.client.SrampAtomApiClient.query(SrampAtomApiClient.java:627) [s-ramp-client-0.3.1.Final-redhat-7.jar:0.3.1.Final-redhat-7] at org.overlord.dtgov.jbpm.util.KieSrampUtil.isSRAMPPackageDeployed(KieSrampUtil.java:51) [classes:] at org.overlord.dtgov.taskapi.TaskApi.configure(TaskApi.java:108) [classes:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45] Nevertheless, if this is the recomended way how to configure dtgov to use remote s-ramp, installer should support specifying such shared keystore, do you agree? I agree that ideally the installer should have a way to install a shared keystore if we plan to instruct users to install dtgov and s-ramp on different servers. It's a difficult problem to manage. I wonder if perhaps we have something similar in another product?? Reading through this again, I think I missed the part about getting a new auth related error. Sorry about that. The second error is possibly because the s-ramp authentication credentials dtgov is using for back-end work are not properly configured. Basically the s-ramp server needs to be configured with a 'dtgovworkflows' user. That user is then configured in dtgov so that the dtgov backend can use it when talking to s-ramp. So there are two auth mechanisms at play here - saml bearer token *and* basic auth, depending on what dtgov is doing. That said, I need to set this up and make sure I can get everything working myself. This product has been discontinued or is no longer tracked in Red Hat Bugzilla. |