search

sul-dlss / argo

The administrative discovery interface for Stanford's Digital Object Registry
Other
20 stars 5 forks source link

argo users must be granted access through sdr: stemmed workgroups #1060

Closed jmartin-sul closed 5 years ago

jmartin-sul commented 6 years ago

we should stop granting users access through all other workgroups, because it will be easier to query for the workgroups argo cares about if they are all under a single prefix (which UIT can give us broader query access to).

see also, argo's .htaccess file generation, used to control access to specific objects managed by the argo application: https://github.com/sul-dlss/argo/blob/f078781ce07fb31004b492ea97d471d8fb7feba3/lib/tasks/argo.rake#L44-L77

jmartin-sul commented 6 years ago

@julianmorley or @eefahy, please correct the above description if need be

blalbrit commented 6 years ago

Thanks @jmartin-sul - can someone weigh in on an appropriate timeline for this work?

blalbrit commented 6 years ago

So @vivnwong has set this as a high priority - but I could use some interpretation. Is this something that needs to be done this week and I should drop other planned work? I'm happy to help out, but I do need some guidelines.

Also, while I know which sdr: stemmed workgroups are in use, I'm not sure of all of the other non-sdr: workgroups currently in use in Argo. Is there a quick way of grabbing those? If not, I can trawl solr for them - but would be happy to hear that we have a quick reference. @eefahy - Vivian mentioned that you might have such a list already?

vivnwong commented 6 years ago

Hi Ben, I would like to put this in a very high priority. The workgroup setup needs to be completed before the developer can start the Shibboleth migration for AGRO. Thanks.

blalbrit commented 6 years ago

Thank you @vivnwong - I do understand that this is high priority. However, I'm looking for timeline - does this need to be done tomorrow? It will take some time to migrate users to different workgroups, and then replace those workgroups in the APOs that hold them. I'm fine with doing the work - but want to set expectations. @jcoyne and @aaron-collier - if you can give me a sense of what you need, I can try to hit that target.

The list of workgroups that will need to be shifted is:

WebAuthLdapPrivgroup cesta:lanciani-archive WebAuthLdapPrivgroup dlss:admin-docs WebAuthLdapPrivgroup dlss:argo-access-ars WebAuthLdapPrivgroup dlss:argo-access-engineering WebAuthLdapPrivgroup dlss:argo-access-spec WebAuthLdapPrivgroup dlss:developers WebAuthLdapPrivgroup dlss:dlss-developers WebAuthLdapPrivgroup dlss:dor-admin WebAuthLdapPrivgroup dlss:dor-manager WebAuthLdapPrivgroup dlss:dor-viewer WebAuthLdapPrivgroup dlss:dpg-hourlies WebAuthLdapPrivgroup dlss:dpg-staff WebAuthLdapPrivgroup dlss:forensics-staff WebAuthLdapPrivgroup dlss:gis WebAuthLdapPrivgroup dlss:pmag-staff WebAuthLdapPrivgroup dlss:production-coordinators WebAuthLdapPrivgroup dlss:smpl-staff WebAuthLdapPrivgroup law:digital_repository WebAuthLdapPrivgroup sul:dig-staff WebAuthLdapPrivgroup sul:dlss-psm WebAuthLdapPrivgroup sul:htext WebAuthLdapPrivgroup sul:map-hourlies WebAuthLdapPrivgroup sul:map-staff WebAuthLdapPrivgroup sulair:dpg-staff WebAuthLdapPrivgroup sulair:kdurante WebAuthLdapPrivgroup sulair:map-hourlies WebAuthLdapPrivgroup sulair:map-hourlies WebAuthLdapPrivgroup sulair:map-staff WebAuthLdapPrivgroup sulair:music-staff WebAuthLdapPrivgroup sulair:spec-staff

Some of these appear in nearly every APO in the repository, so it will take some time to do the work.

jcoyne commented 6 years ago

I understood the requirement here to be: a list of defined workgroups, and only a single stem of sdr. Is that your understanding @eefahy & @julianmorley?

blalbrit commented 6 years ago

@jcoyne - that's my understanding too. What that means, from a service perspective, is the creation of a lot of new workgroups and migration of existing users into those workgroups, and then replacement of existing non-sdr: workgroups in APOs with the new ones.

I would be very happy to know if that is what you all are thinking as well.

blalbrit commented 6 years ago

Group created - sdr:argo-access

Have currently nested all non-sdr workgroups within that.

@jonrober - would you recommend simply nesting all workgroups (including those with sdr stems)? Just looking for the easiest long-term maintenance approach here.

Jon has confirmed this would be a prudent approach.

blalbrit commented 6 years ago

@jonrober @jcoyne @aaron-collier

sdr:argo-access now has all workgroups mentioned in Argo, regardless of stem. Please keep me in the loop through next steps, and ping me if you need anything from me.

jonrober commented 6 years ago

Thanks! I have a branch on puppet ready to do a PR for when people are good, that will put that group in the Apache configuration directly rather than in the .htaccess file. If I understood correctly from this morning's meeting, that's what we'd wanted to do. But some questions off of that:

blalbrit commented 6 years ago

@eefahy - for the other content in the .htaccess file, is that needed after we move to a single umbrella workgroup?

jonrober commented 6 years ago

Yes it is, as we've discovered. :) That content is now all in the system Apache configuration.

jmartin-sul commented 6 years ago

transcription of slack chat, to clarify how roles and workgroups have to be configured going forward:

@jmartin-sul [13:17] my understanding was that non-sdr: workgroups would be totally unsupported under shib (discussed at standup yesterday, got some clarification from @jonrober, will leave a comment summarizing on the github issue). but my understanding was also that .htaccess was still being generated on prod, and so prod should still be working as before, since it's still under webauth.

@jonrober [13:21] Yes on John’s. Non-sdr: workgroups won’t work under shibboleth. What came up primarily yesterday was the question of whether a non-sdr: workgroup nested under sdr: would work, where I realized we hadn’t spelled out the full story. They will work for access but not if you’re trying to get the list of what non-sdr: group the user is a member of. [which argo requires for its permissions mapping]

There’s nothing in either webauth or shibboleth that says "this user got access through group B because B nests C which the user is in". Current argo under webauth handles by just saying "Require groups B, C, and D for access", then "And tell an environment variable if user is in B, C, or D". Shibboleth doesn’t have the two separate operations and just says "Here are all the groups (that the app has privilges to see) that the user is in", and that list is both used for determining access and is fed to the environment.

Argo-shibboleth only has access to the sdr: groups because shib can’t do the same granularity as webauth. So effectively it can use nesting a non-sdr: group for determining Apache access (since from a data standpoint in LDAP it just shows as the user being in the sdr group that’s doing the nesting), but it can’t tell you that the non-sdr: group was used. That’s a wrinkle that didn’t come up til yesterday’s standup — it’s something that I never thought through before end to end.

@jmartin-sul [13:56]

nice, thanks @jonrober for the well stated summary! unfortunately, the upshot for @blalbrit is that we can't cut over to shibboleth until the APOs have been migrated to only grant access via sdr: workgroups. or at least that's my takeaway from all of the above, since i think those are the only workgroups that argo will be able to get info about in the headers, and so will be the only workgroup info it has available for mapping to user roles.

the tentative plan (from @blalbrit) is to migrate users entirely into sdr: workgroups sometime mid to late next week (5/14-5/18). @lauraw15 is setting up a couple of working sessions so they can get everyone moved over.

blalbrit commented 6 years ago

Quick update: all new workgroups have been created and populated.

Next step is to edit the APOs, switching in the new workgroups for the old. I'll do this in -stage tomorrow and if that works, then we'll coordinate switching them in for -prod as well.

@vivnwong ^^ the coordination part is important here, I'll talk it through with @jcoyne on Friday.

blalbrit commented 6 years ago

Have updated a number of APOs on -stage and things are looking good. I can see the superset of APOs in registration, and when impersonating various of the new workgroups I can see the subsets filtered as expected.

I'm going to make the changes in prod over the weekend.

vivnwong commented 6 years ago

Hi Ben,

Thank you for the update. I am sorry the Shibboleth upgrade added unexpected workload to your already busy schedule, I really appreciate you can make this work a priority.

Thanks

Vivian

On 5/18/2018 5:06 PM, Benjamin Albritton wrote:

Have updated a number of APOs on -stage and things are looking good. I can see the superset of APOs in registration, and when impersonating various of the new workgroups I can see the subsets filtered as expected.

I'm going to make the changes in prod over the weekend.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sul-dlss/argo/issues/1060#issuecomment-390362004, or mute the thread https://github.com/notifications/unsubscribe-auth/AeD7v0gcwQ-gZxZi7TmmGtjEcSYz-ua3ks5tz2IJgaJpZM4Ts8W2.