Honeybadger reported issues related to authcheck attribute and access to articles+

[saseestone]

Chris alerted me to honeybadger issues reported after we updated our check for eduPersonAffiliation:member in our auth check.

See: https://github.com/sul-dlss/SearchWorks/issues/3690

The following two users had issues, as reported by honeybadger:

• ejharvey
• atswain

Looking at Regadmin, this is what I see for each user:

• For ejharvey - the user does have suPrivilegeGroup = stanford:library-eresources-eligible. They have two active affiliations. -- suGwAffilCode1 = stanford:affiliate:sponsored -- suGwAffilCode2 | stanford:student:recent, effective:2022-09-01, until:2027-08-31

• For atswain - the user does have suPrivilegeGroup = stanford:library-eresources-eligible. They have only one affiliation. -- suGwAffilCode1: stanford:student, until:2024-04-01

For both users, the eduPersonAffiliation:member check should have worked.

[corylown]

I'm guessing this is one of the relevant errors in honeybadger: https://app.honeybadger.io/projects/50022/faults/104567265

Maybe we ought to be logging the value of eduPersonAffiliation as well, since we currently can't see what we're getting back that's causing the privilege check to fall back on suAffliation:

User affiliations and privileges: Not affiliated by eduPersonAffiliation but is by suAffiliation: stanford:student;stanford:staff:student 

[corylown]

Looks like in cases where we're falling back to suAffiliation that the value of eduPersonAffiliation is empty:

User affiliations and privileges: Not affiliated by eduPersonAffiliation: ; Affiliated by suAffiliation: stanford:student;stanford:staff:student;stanford:staff:nonactive

[hudajkhan]

Thank you for putting in the info @corylown ! That's very helpful.

[hudajkhan]

Just for additional context, ejharvey maps to eduPersonPrimaryAffiliation (in regadmin)value "member" while atswain maps to value "student".

[hudajkhan]

Here are a few additional examples from HoneyBadger where eduPersonAffiliation/unscoped-affiliation is not "member" but the user is provided access through 'suAffiliation'

• suAffiliation values are "stanford:student:recent;stanford:student:onleave;stanford:staff:nonactive"

https://app.honeybadger.io/projects/50022/faults/104567265/01HNWZK5T0BN8HEG0928VPQS20?page=0&q=occurred%3A%22%5B2024-02-05+8%3A50+UTC-7+TO+2024-02-05+9%3A00+UTC-7%5D%22%E2%80%81suAffiliation

• suAffiliation values are "stanford:student:recent;stanford:student"

https://app.honeybadger.io/projects/50022/faults/104567265/01HNXV1P1EGD40HTJDRYZH427B?page=0&q=occurred%3A%22%5B2024-02-05+13%3A00+UTC-7+TO+2024-02-05+17%3A00+UTC-7%5D%22%E2%80%81suAffiliation

• suAffiliation is "stanford:student;stanford:staff:nonactive"

https://app.honeybadger.io/projects/50022/faults/104567265/01HNXMP1TED0YGMMSJY78ANY03?page=0&q=occurred%3A%22%5B2024-02-05+15%3A02+UTC-7+TO+2024-02-05+15%3A03+UTC-7%5D%22%E2%80%81suAffiliation

[hudajkhan]

Here is another example where eduPersonAffiliation is not empty but does not equal "member", and suAffiliations is able to allow the user access.

https://app.honeybadger.io/projects/50022/faults/104567265/01HP37WH6Q779PFHQ2727S7TM2?page=1&q=occurred%3A%22%5B2024-02-07+17%3A00+UTC-7+TO+2024-02-07+19%3A26+UTC-7%5D%22%E2%80%81suAffiliation

eduPersonAffiliation = "affiliate" suAffiliation: "stanford:affiliate:sponsored"

[hudajkhan]

In this example, eduPersonAffiliation is empty.
suAffiliation = "stanford:student;stanford:student:nonactive;stanford:staff:nonactive"

https://app.honeybadger.io/projects/50022/faults/104567265/01HP37Z6B3EVN5YFZHZNAW8N1B?page=1&q=occurred%3A%22%5B2024-02-07+17%3A00+UTC-7+TO+2024-02-07+19%3A26+UTC-7%5D%22%E2%80%81suAffiliation

[hudajkhan]

Where we stand right now:

We added sunet info/context to the Honeybadger notification for when a user is covered by suAffiliation but not by eduPersonAffiliation. We are seeing multiple examples where eduPersonAffiliation is empty when suAffiliation has values that should have eduPersonAffiliation map to "member". We have compiled a list and are sharing it to check why the attribute values SearchWorks receives appear to have a discrepancy with whatever LDAP/SAML values are stored.

As a fallback, we have the option to request eduPersonEntitlement to be released.

We are waiting for more info regarding the cause of the discrepancy (if possible) before we make that request.

[hudajkhan]

Based on information we received for specific cases, the SAML/LDAP info shows "member" correctly in eduPersonAffiliation while the attribute info SearchWorks receives is empty for those same cases.

We are filing a ticket with ops to see why these discrepancies exist and if they can be resolved.

[hudajkhan]

For reference, here is the ops issue: https://github.com/sul-dlss/operations-tasks/issues/3615

[hudajkhan]

Ops reports that, when they are trying SearchWorks out for themselves, they do not see a discrepancy between the values they are reading from unscoped-affiliation and the values that should be there.

We will be following up to see if we can get Shibboleth information on a particular user (as identified in the ops ticket above) to see if we can see any discrepancy there.

[hudajkhan]

Trying to resolve/move ahead with two approaches: a) Asking for eduPersonEntitlement b) Also updating Ops ticket stating we have reached out but not heard back yet, and meanwhile there are multiple users showing a discrepancy.

[hudajkhan]

Latest comment in ops: https://github.com/sul-dlss/operations-tasks/issues/3615#issuecomment-1960191342

[hudajkhan]

Also opened: https://github.com/sul-dlss/operations-tasks/issues/3628

[hudajkhan]

Also created this for removing Honeybadger notifications by the end of the workcycle (after documenting the users for whom the notifications were created): https://github.com/sul-dlss/SearchWorks/issues/4016

[hudajkhan]

Closed by #4085

[hudajkhan]

Will close this as ops tickets closed and we can't get any more information at the moment. Hoping that #4082 will provide the information we need. @saseestone just checking in if that's ok.