[not sure where exactly to post this, let me know … ]
In one of my notebooks, I need to use authenticate against another SSO service, so at present I’m using the “cern-get-sso-cookie” with the “–krb” option. To use that, I will have to open a swan-terminal first and do a 'kinit". So far, so good.
Other people (from outside CERN) who use a clone of that notebook say that they loose the token frequently during a session, so I’m wondering if there is another way to do this kind of “re-authorisation” – after all, the SWAN session and the notebook are already SSO authenticated.
So here is my question: is there a way to get access to “forward” the SSO authentication from SWAN to another, different, URL ? If SWAN would keep somewhere the krb token around, I could use that one, for example …
When you start a SWAN session, we get you a “limited” kerberos ticket that allows you to access your CERNBox. We make sure that ticket is refreshed as long as your session is alive. Recently, we have also added the capability to submit to Spark clusters without retyping your password, but that is it I’m afraid.
The SWAN users you mention, they say they lose frequently the token they created with cern-get-sso-cookie. How often is frequently in this case? Do they lose it even without restarting their SWAN session?
I quote here from a mail I got today: “It was so severe yesterday that we connected probably only a few times in 2 hours! It was just painful.” I’m not sure if they got disconnected and ended up on a different node after re-connecting, will try to see if I can get that info.
Could you please let me know where the “limited” ticket is stored ? As far as I understand it, the cern-get-sso-cookie looks in the usual /tmp/krb_XXXX location, so if I could simply copy the limited ticket over to there and re-use it (assuming it would be “good enough”, that would be good.
The kerberos ticket is not visible from inside your container (session). But even if it were visible, it is no use for any service that is not CERNBox anyway.
Just a few comments about losing the tickets:
If a SWAN user keeps working on their session, the ticket they generated with cern-get-sso-cookie should be there and usable until it expires. We garbage collect user sessions after 6 hours of inactivity.
If a SWAN user connects to a different SWAN machine and opens a new session, it is expected that no ticket will be available there since a new container is created for them. Note that this would not happen if the user created the ticket on their CERNBox space (instead of in the container): they would just need to point to it from the second session.
I got more info from the user, which is confusing to me … just after starting SWAN, he does a kinit in the SWAN terminal, then klist which shows the token, still the cern-get-sso-cookie fails and prompts with the SSO login page. Do you want me to continue the discussion with the details here or do you prefer a SNOW ticket ?
I just got a short screenshot movie from the user, you can find it in [1] below. The issue seems that the cern-get-sso-cookie does not recognise/use/… the krb token created by kinit in the clone of the shared project, while it does work in my original project area.
The sequence is to setup SWAN for the 95a_Python3 environment, then start the terminal, do kinit there, provide the pwd, check with klist, then open the cloned project [2], run the cells of the script and see that in cell 5 the authentication fails. The “dump” of the result page from cern-get-sso-cookie shows the standard CERN SSO login page [3].
The user can login on the application (in a different location) which is used for the cern-get-sso-cookie …
So in your user account the whole sequence works perfectly, but not in the account of this user? The creation of the kerberos ticket is not related in any way with the SWAN projects, so that is not the reason.
Could the user try to do a similar sequence of steps from lxplus?
Something else I was thinking of was trying to create an SLC6 session instead of CC7 and see what happens. But if you say it works for your user in CC7, it must be something else.
,
