YAP on Esignature and SSO

[avillanueva]

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:

1. Has anyone successfully configured eSignature to re-auth with SSO? What's the user experience like? Screenshot?
2. 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? 
3. 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?
4. 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?

[jbailey · Accepted solution]

1. Yes
2. You add a path for reauthsecure in the host name section in the <RequestMap> subelement of the <RequestMapper> element
3. It will be a popup window that looks like your Windchill SSO
4. 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.

shibboleth2.xml additions

  <RequestMapper type="Native">

        <RequestMap>

                      <Host name="<YOUR HOST>" scheme="https" port="443">

            <Path name="secure" .../>

<!-- added below to allow for reauth on esignatures -->

<Path name="reauthsecure" authType="shibboleth" requireSession="true" ... applicationId="reauthsecure" />

            </Host>

        </RequestMap>

    </RequestMapper>

The settings in ApplicationOverride are similar to the settings to the application default.

<ApplicationOverride id="reauthsecure" entityID="<WC ENTITY ID>" 

REMOTE_USER="<YOUR ATTRIBUTES>" 

cipherSuites="<YOUR CIPHER SUITES>" >

<Sessions>

<SSO>

</SSO>

</Sessions>

       <MetadataProvider>  </MetadataProvider>

</ApplicationOverride>

</ApplicationOverride>

    </ApplicationDefaults>

00-1mod_shib.conf additions 

#

<Location /reauthsecure/Shibboleth.sso>

   AuthType None

  require shib-session false

</Location>

#

Alias /Windchill/reauthsecure/ "/reauthsecure/Shibboleth.sso/Login"

<Location /reauthsecure>

   AuthType shibboleth

  ShibRequestSetting applicationId reauthsecure

   require shib-session

</Location>

30-app-windchill-1auth.conf additions

<LocationMatch ^/+Windchill/reauthsecure?>

  AuthType shibboleth

  ShibRequestSetting applicationId reauthsecure

  ShibUseHeaders on # mod_jk doesn't pass environment, so useHeaders is required

  require shib-session

</LocationMatch>

wt properties / xconf

 <Property name="wt.org.electronicIdentification.class" overridable="true"

             targetFile="codebase/wt.properties"

             value="wt.workflow.engine.SSOConfiguredSignatureEngine"/>

   <Property name="wt.servlet.sessionCookiePattern" overridable="true"

             targetFile="codebase/wt.properties"

             value="_shibsession_.*"/>

   <Property name="wt.servlet.sessionCookie" overridable="true"

             targetFile="codebase/wt.properties"

             value="JSESSIONID"/>

Additionally, if you use an attribute other than uid for authentication for WC, you need to change it like this (change uid to whatever attribute you need) :

<Install location>\Windchill_12.0\Windchill\codebase\reauthsecure\SSOReauthentication.jsp

<%

    HttpSession sessionHttp = request.getSession();

    request.getSession().setAttribute("newIDPAuthorizedUser", request.getHeader("uid"));

%>

[avillanueva]

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?

[jbailey]

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