Bug 1372087 - SSO Docs: Keystore for WebEndpoint uses a different name than JGroups Key/TrustStore
Summary: SSO Docs: Keystore for WebEndpoint uses a different name than JGroups Key/Tru...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat xPaaS
Classification: Red Hat
Component: Documentation
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
Assignee: Andrew Burden
QA Contact: Tomas Schlosser
Vikram Goyal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-31 21:08 UTC by Eric Rich
Modified: 2017-05-22 02:26 UTC (History)
0 users

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-22 02:26:09 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Eric Rich 2016-08-31 21:08:00 UTC
Description of problem:

4.1.2. Deploying the SSO Application Template, the same secrete seems to be used for JGroups and Web SSL traffic. 

JGROUPS_ENCRYPT_SECRET and SSO_TRUSTSTORE_SECRET (in the tables) use the same name for the secrete value ( sso-app-secret ). This seems to be done for example purposes. 

> However I would suggest adding a note in: 
> https://access.redhat.com/documentation/en/red-hat-xpaas/version-0/red-hat-xpaas-sso-image/#preparing_sso_authentication_for_openshift_deployment
>  that explains that the CA/[Key|Trust]Store process may need to be repeated, or duplicated for web traffic. 

In addition to this the JGROUPS_ENCRYPT_KEYSTORE and SSO_TRUSTSTORE use different values. 

> Is this on purpose? are these the names of the "file locations" in the pods where the secretes are stored, so that the SSO components (JGroups / Underdow) can reference them?

Comment 2 Andrew Burden 2017-03-31 09:38:46 UTC
I've updated the secrets commands, and use two secrets (one each for jgroups, and for the keystore and trustore) as standard instead of one. This is now consistent through get_started and tutorials. 
Also the tutorials now create EAP keystores for the EAP applications rather than using the same SSO ones, as this seems like good practice even for an example.

Eric, to answer your last point: yes. those values are the keystore/truststore file names for reference within the secret.


Note You need to log in before you can comment on or make changes to this bug.