SessionCache and Session Recovery

[Shu Gao]

Thanks, Scott. The issue with our Python script was resolved for now, it seems to be a session management issue in the script.

But there is a new issue with the SSO login in web browser - although I cannot replicate it, but some users' login got into a loop between IDP and SP. I read Shibboleth wiki pages on looping and debugging, but still don't have a clue.

Our SP has 3 servers behind a load balancer, the request could hit any of them. What I observed is that after the client was redirected back to ACS,  a new RelayState token cookie was generated, and redirected back to the IDP. The shibd.log didn't give any error or warning, but I think the fact that the RelayState token value keeps changing indicates something wrong. Is any log file that I can find some error message? Without an error message, I don't know what to fix. From the HAR file I recorded, all connections are https, and we set  consistentAddress="false" checkAddress="false". I found the clock on one of the 3 servers was off by 50s, that is not good but shouldn't cause the looping issue, right? My <SPConfig> has 'clockSkew=300'.



On 6/27/22, 3:17 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

    WARNING: This message originated from outside the organization. Exercise caution when opening any attachments or clicking on links.


    On 6/26/22, 2:28 PM, "users on behalf of Shu Gao via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

    >    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.

    That's not supported, except for the ECP endpoint. If you want to screen scrape, you are on your own.

    > After we upgraded SPv2 to SPv3, the Python client stopped working.

    That is exactly why it's not supported. You will never make that work other than coincidentally and sporadically, and you shouldn't try. That is not the proper solution to whatever problem you're trying to solve.

    >    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)?

    Don't know, don't care. See above. If you want to know, look at the logs, trace cookies, etc. I'm sure it's cookies in some form.

    >    2. Do we need to enable "Session recovery" in <SessionCache> to support multiple SP servers?

    That depends on the app, but generally you either need a persistent storage back-end, a shared shibd (which won't scale and isn't supported), or the recovery option, or possibly just sticky load balancing.

    >    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?

    That’s the only type ever implemented.

    >    4. For session recovery, what values I can use for persistedAttributes?

    The local attribute IDs you happen to use in the SP based on the attribute extraction step that takes place.

    >    5. Is it right - to use <DataSealer>, I have to remove <StorageService> and use the default values?

    No, it's not, that's orthogonal. You can, though likely wouldn't, use a database for storage while still using the cookie feature.

    -- Scott




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.
Thanks, Scott. The issue with our Python script was resolved for now, it seems to be a session management issue in the script.

But there is a new issue with the SSO login in web browser - although I cannot replicate it, but some users' login got into a loop between IDP and SP. I read Shibboleth wiki pages on looping and debugging, but still don't have a clue.

Our SP has 3 servers behind a load balancer, the request could hit any of them. What I observed is that after the client was redirected back to ACS,  a new RelayState token cookie was generated, and redirected back to the IDP. The shibd.log didn't give any error or warning, but I think the fact that the RelayState token value keeps changing indicates something wrong. Is any log file that I can find some error message? Without an error message, I don't know what to fix. From the HAR file I recorded, all connections are https, and we set  consistentAddress="false" checkAddress="false". I found the clock on one of the 3 servers was off by 50s, that is not good but shouldn't cause the looping issue, right? My <SPConfig> has 'clockSkew=300'.



On 6/27/22, 3:17 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

    WARNING: This message originated from outside the organization. Exercise caution when opening any attachments or clicking on links.


    On 6/26/22, 2:28 PM, "users on behalf of Shu Gao via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

    >    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.

    That's not supported, except for the ECP endpoint. If you want to screen scrape, you are on your own.

    > After we upgraded SPv2 to SPv3, the Python client stopped working.

    That is exactly why it's not supported. You will never make that work other than coincidentally and sporadically, and you shouldn't try. That is not the proper solution to whatever problem you're trying to solve.

    >    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)?

    Don't know, don't care. See above. If you want to know, look at the logs, trace cookies, etc. I'm sure it's cookies in some form.

    >    2. Do we need to enable "Session recovery" in <SessionCache> to support multiple SP servers?

    That depends on the app, but generally you either need a persistent storage back-end, a shared shibd (which won't scale and isn't supported), or the recovery option, or possibly just sticky load balancing.

    >    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?

    That’s the only type ever implemented.

    >    4. For session recovery, what values I can use for persistedAttributes?

    The local attribute IDs you happen to use in the SP based on the attribute extraction step that takes place.

    >    5. Is it right - to use <DataSealer>, I have to remove <StorageService> and use the default values?

    No, it's not, that's orthogonal. You can, though likely wouldn't, use a database for storage while still using the cookie feature.

    -- Scott




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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220701/daecac68/attachment.htm>