<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Times New Roman \(Body CS\)";
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:"Andale Mono";
        panose-1:2 11 5 9 0 0 0 0 0 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head><body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:14.0pt">We have 2 types of clients using SSO login to access our Shibboleth SP, one is web based, the other one is using a script written in Python. After we upgraded SPv2 to SPv3, the Python client stopped working.
 The Python script gets itself authenticated by the IDP then it is redirected back to the SP. The SP checks the SAML2 assertion, creates a session, and redirects the Python script to the URL specified by 'sessionHook'. At this step, the Python script is redirected
 to the IDP again, which fails the login. There is no ERROR or WARN log message found in any log.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">Our SP has multiple servers and each runs an Apache webserver. Previously we used a shared shibd process running on a separate server for sharing session data among these servers. After upgraded to SP3, we
 started to run a shibd process on every server and rely on cookie to share session data. Currently, we don't have "Session recovery" explicitly enabled.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">Current configuration (only the part I think is related):<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <!-- This set of components stores sessions and other persistent data in daemon memory. --><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <StorageService type="Memory" id="mem" cleanupInterval="900"/><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <SessionCache type="StorageService" StorageService="mem" cacheAssertions="false"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">                  cacheAllowance="900" inprocTimeout="900" cleanupInterval="900"/><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <ReplayCache StorageService="mem"/><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">I tried the following configuration, but it seems the values for â€˜persistedAttributes’ are not right.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <DataSealer type="Static" key="MjM0bzA5OTQ1OXUyaXRrbGt3ZTA5Zzk0aGd5Z3Z2aHZ2aGhiICBlcjUzNG5rZGx =="/><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <!-- This set of components stores sessions and other persistent data in daemon memory. --><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <!-- <StorageService type="Memory" id="mem" cleanupInterval="900"/> --><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <SessionCache type="StorageService" cacheAssertions="false"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">        cacheAllowance="900" inprocTimeout="900" cleanupInterval="900"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">        persistedAttributes="shibb_agency_id shibb_email shibb_first_name shibb_guid shibb_idp_user_id shibb_last_name shibb_phone_number shibb_district_divis<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">ion"/><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">    <ReplayCache /><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">My questions are:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">1. What could be the possible reason that the Python script is redirected back to IDP even after Shibboleth has checked the SAML assertion and is OK with it (at least it appears to be)?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">2. Do we need to enable "Session recovery" in <SessionCache> to support multiple SP servers?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">3. The documentation says <SessionCache> can be omitted, result in <StorageService> cache type being used. And if it is not omitted, the only implemented 'type' is 'StorageServiceSessionCache'. It sounds to
 me 'StorageServiceSessionCache' is the same as the default <StorageService> cache type?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">4. For session recovery, what values I can use for persistedAttributes?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">5. Is it right - to use <DataSealer>, I have to remove <StorageService> and use the default values?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt">Thank you advance for your attention!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:14.0pt"><o:p> </o:p></span></p>
</div>
The content of this e-mail message and any attached files transmitted with it are to be treated as confidential information and are intended solely for the use of the individual or entity to whom they are addressed. If the reader of this e-mail is not the intended
 recipient or his or her authorized agent, the reader is hereby notified that any reproduction, distribution, or disclosure of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete
 this e-mail immediately.***1010data, Inc. and its affiliates ("1010data") are not responsible for any advice concerning the use of its software or services or the data manipulated by its software, except to the extent 1010data has specifically undertaken such
 responsibility in a validly binding contract. 1010data shall have no responsibility for any decision concerning the appropriate method of use or application of its software or services or the data therein in connection with any transaction. Any decision concerning
 how, where and when to use this facility remains the sole responsibility of the user. NO AGREEMENTS MAY BE ENTERED INTO WITH ANY 1010DATA COMPANY VIA EMAIL EXCHANGE REGARDLESS OF THE TITLE OF THE AUTHOR OF THE EMAILS. ALL AGREEMENTS MUST BE IN THE FORM OF
 A FORMAL WRITTEN AGREEMENT SIGNED BY THE CHIEF EXECUTIVE OFFICER, PRESIDENT, CHIEF OPERATING OFFICER, CHIEF FINANCIAL OFFICER OR CHIEF PEOPLE OFFICER OF 1010DATA AND AN AUTHORIZED REPRESENTATIVE OF THE OTHER PARTY.


</body></html>