YAP on Esignature and SSO
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
YAP on Esignature and SSO
Yet Another Post of Esignature and SSO. Moving on from my previous post, and reading the docs on the setup, I have a few questions:
- Has anyone successfully configured eSignature to re-auth with SSO? What's the user experience like? Screenshot?
- Docs mentioned added to <Hosts> block that that is not part of the default shibboleth2.xml file. That also requires <RequestMapper> and <RequestMap> sections. Is there an error in docs?
- I have been currently been using JNDI connector to AD for years. Presents as a password field but does not impact browser session or re-auth. How would SSO be different? Can we just leave JNDI connection as is? Is other option safer, more secure or easier on the end user?
- Docs alluded to browser caching. Whole point of esignature was forcing user to confirm you are you. Relates to #1, what does it look like for end user?
Solved! Go to Solution.
- Labels:
-
Bus_System Administration
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
- Yes
- You add a path for reauthsecure in the host name section in the <RequestMap> subelement of the <RequestMapper> element
- It will be a popup window that looks like your Windchill SSO
- It is all part of the popup window, should be relatively seamless. The way the process works is it uses the SSOReauthentication.jsp gets the user id from the Windchill session and in the new window a fresh session is created., Windchill then checks the username and compares it to the logged in user. if they don't match - then it will fail.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
- Yes
- You add a path for reauthsecure in the host name section in the <RequestMap> subelement of the <RequestMapper> element
- It will be a popup window that looks like your Windchill SSO
- It is all part of the popup window, should be relatively seamless. The way the process works is it uses the SSOReauthentication.jsp gets the user id from the Windchill session and in the new window a fresh session is created., Windchill then checks the username and compares it to the logged in user. if they don't match - then it will fail.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
Is the entityID for the ApplicationOverride different or the same as the default section? I was also confused about the initial configuration regarding the /secure path. It was listed as a default in 00-1mod_shib.conf. I interpreted that to be just a place holder for the location you want to secure. Seeing as the other confs define the /Windchill locations to be secured, it commented this block out. I noticed it appear again in PTC's instructions with the Host block. Am I correct in that the Location /secure was just an example?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Notify Moderator
It is usually the same, unless you want to do something special (we have tested special things) but it can be the same.
And no on that assumption... The /secure is the default location and needs to be there it is like a virtual location that encompasses Windchill
