Karaage-Cluster/karaage

Confusion if logging in with wrong shibboleth account

Closed this issue · 6 comments

If you have multiple shibboleth account accounts, and you log in with the wrong one, then:

  1. Karaage will return to the root index page, with no indication why.
  2. Attempting to log in again will redirect to the new application process.

From Karaage's point of view, this makes sense:

  1. We cannot log the user in, as we cannot associate the shibboleth identity with an account.
  2. We cannot revoke the shibboleth session without closing the window.
  3. As we don't know the user the most likely cause of action is to sign them up as a new user.

From the User's point of view, this is completely confusing:

  1. My shibboleth login didn't work. I do not know why it didn't work.
  2. It won't let me try to log in again. It takes me to the application process. I don't know why. I already have an account.
  3. It is possible to login in by going directly to the /karaage/profile/login/ URL, but no link is provided, and most users wouldn't know this.

This process needs to be improved.

If we know the user has a shibboleth identity but not an existing account could we direct them to a page to tell them this and then offer them either the option to close the window and login again with the correct account if they know they already have one or the option of trying to create an account or the option of contacting the support team?

Yes, this is probably a better option. Now need to consider if this is possible or not. Problem is that we have no easy way of distinguishing the case of "this user just logged into Shibboleth" vs "this user logged into shibboleth a while ago and should be allowed to navigate the site normally" because shibboleth authentication occurs completely outside Karaage's control with the Apache shibboleth module. In fact, the user could log in Shibboleth in another window when Karaage really is not expecting it. Maybe we could store the shibboleth identity in the user's session and take action if it changes.

Something is possible but requires more consideration. Otherwise, we could have a solution that fixes this corner case but creates new corner cases.

Now need to consider if this is possible or not.

Ah, OK.

Otherwise, we could have a solution that fixes this corner case but creates new corner cases.

You are lost in a maze of twisty corner-cases, all alike. You may be eaten by a grue.

I wrote a proposed solution, however I suspect it might mess up the new application process (part of the problem here, fix one problem and you create another). Plus the fact I can't easily test shibboleth from my laptop... Need to try to come with with a better way of testing shibboleth, a testing VM might be rather useful here.

Shib is supposed to be fairly agnostic here, and the IdP is the ultimate immediate authority on how tokens are constructed, etc.

The application will only ever be able to do so much with scenarios outside shib's projected cases (e.g. bad SAML token generation, multiple user AD accounts & user account confusion, etc).

IIRC I fixed this problem when converting to use Rapid Connect. Closing.