1

I have a database-backed web application, with authentication via organizational single sign-on, modeling a library lending system for digital books. I'd like to allow users to check out books and see what they've checked out, without allowing myself or other administrators to keep track of who's checked out what. I also have a requirement to keep stats on the number of unique users.

Ideas I've considered so far:

  1. put the SSO user ID in the loan record, but clear it on return/expiry
    • pros:
      • user can get to their checkouts, even from a different device
    • cons:
      • we do have the data in the database, even if it's only while the book is checked out
      • unclear how to count unique users
  2. instead of storing the UID, generate a random token and set it in a cookie
    • pros:
      • loans are never connected to UIDs in the database
      • can sort of count unique users, or at least browsers
    • cons:
      • users can't clear cookies or switch browsers
      • not quite counting unique users
  3. hash the UID instead of using the real ID, and store the hash in the loan record
    • pros:
      • user can get to their checkouts, even from a different device
      • actual UIDs aren't connected to loans
      • can count unique users
    • cons:
      • trivial to re-hash a given UID and from that, connect users back to loans
  4. make users create a password/passphrase, hash that along with the UID, and use that hash instead of the UID
    • pros:
      • as (3) above, plus
      • having the UID isn't enough to connect you to the loan
    • cons:
      • users won't see the value in having to do this, and will be annoyed
      • unclear how to track unique users
  5. generate a one-time token, and give/email the user a URL that includes the token, which they have to use if they want to get back to the checkout. Hash that token with the UID, and use that hash as the user identifier in the database.
    • pros:
      • as (4) above
      • doesn’t require users to do anything
    • cons:
      • still a little rickety, possible for users to lose the URL
      • unclear how to track unique users

Is there anything better than #5? I feel like this must be a solved security/crypto problem, but I'm blanking on the solution.

4
  • Do you or adminstrators have access to the authentication server? Commented Jun 2, 2021 at 22:34
  • @pcalkins No, we just redirect to the SSO service (CAS) and get back a list of (mostly) LDAP attributes on a successful login. Commented Jun 2, 2021 at 22:46
  • if those attributes can't be tied to a particular user, then you're good to go. They're effectively anonymous users. Doesn't seem like you need anything special here. Commented Jun 4, 2021 at 16:33
  • @pcalkins The nasty bit is that I do need something tied to a particular user in order for that user to see their own particular checkouts — it's not enough to say, just authorize everyone in a particular LDAP group. Commented Jun 4, 2021 at 21:24

0

You must log in to answer this question.

Browse other questions tagged .