Devolved Federated Group Management?

[Adam Carrgilson]

Hi all,

 

I’ve got an interesting federation query on my plate.

 

My scenario, I host an iRODS setup where all my users authenticate against one zone to get access a whole host of federated zones; this is to ease the management burden of user authentication by centralising it, and to allow us to devolve administration of zones to their respective owners.

 

My query comes from one particular owner, who is responsible for several of the zones. They want to consolidate their group management activities, such that they only manage one zone’s worth of users & groups where there is obvious overlap between zones. I’m really interested in this particular question because I can see it becoming more relevant as different folks start using iRODS here.

 

Now I’m guessing this should be quite easy with federation, but because my users are all using federated accounts by the time they get to the zone they need, how do I approach this?

Do I federate this group management zone with both my authentication zone and all zones where those groups will be used? Will that work?

 

Is anybody else using a similar approach?

What I'm imagining is something like this:

Thanks in advance!

Adam.

[Terrell Russell]

I have not seen this done myself - but the documentation and a quick local test suggest that it's possible to add remoteZone users into groups.  Those groups could then be used, themselves, in another remoteZone to grant access.  I think this is the use case in your diagram, so my tentative answer is yes, this should work in principal.

Please test and check that the ACLs are enforced as expected.  This will be an excellent set of test scenarios to get into our test suite.

Let us know,

Terrell

--
--
"iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat

---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Constable]

I took a look, because I realized I didn’t understand how this should work (I may still not…);

In a very unscientific or rigorous test, adding groups in an ACL from another federated zone didn’t work, but users did. In our Federated production setup, we tend to add users from the top level federated zone, to groups within the zone, so we may not have tested this when we did our 3.3.1->4.x migration, either, and certainly none of our users have raised it with us..

 

Group and user exist on one zone;

irods-sanger1-dev:~$iadmin lg johntest

Members of group johntest:

jc18#Sanger1-dev

 

add in an ACL to another:

@irods-g1-dev:~$ ichmod read johntest#Sanger1-dev /seq-dev/home/irods-g1-dev/test2999.txt

ERROR: rcModAccessControl failure  status = -827000 CAT_INVALID_USER

irods-g1-dev@irods-g1-dev:~$ ichmod read jc18#Sanger1-dev /seq-dev/home/irods-g1-dev/test2999.txt

ils -A /seq-dev/home/irods-g1-dev/test2999.txt

  /seq-dev/home/irods-g1-dev/test2999.txt

        ACL - irods-g1-dev#seq-dev:own   jc18#Sanger1-dev:read object

 

However, I may have omitted or forgotten something..

--

To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

--

--
"iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat

---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.

To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.

[Adam Carrgilson]

Hi John,

I've tested this out as I documented and I replicate exactly the same error you get, ERROR: rcModAccessControl failure  status = -827000 CAT_INVALID_USER.

I had hoped that this would have worked, but it looks like groups aren't enumerated across federations?

Terrell, you mentioned that in principle the behaviour sounds appropriate, is there any output I can provide to make this clearer and see if we can get it working?

Many Thanks,
Adam.

[Nordgren, Bryce L -FS]

Summary: I think the question of centralizing authorization exposes the need for an “authorization plugin interface” where the plugins can speak “local database”, LDAP/AD/FreeIPA, oAuth2/OpenID Connect(?)/SAML, or whatever language a Virtual Organization speaks. Of these I am most familiar with LDAP/AD/FreeIPA.

 

Long version:

I’ve been thinking about these same kinds of issues in a variety of different situations for a while. Fundamentally, the model typically employed when the word “federation” is used is the connection of unrelated organizations with unique sets of users. You (and I) tend to be thinking of a situation where people want to access a common set of users but have local control over what those users are allowed to do on the local equipment. Centralizing group definitions gives away some of that local control to a foreign entity, just as delegating the authentication function does. Certainly not impossible, but I wouldn’t expect to see it within iRODS until iRODS starts to speak a language designed to communicate authorization information (OAuth2, etc.). I see no reason for iRODS to re-invent the wheel here. My forte is not grid oriented solutions, but from what little I know, centralized authorization appears to be an essential function of a “virtual organization”?

 

In the mean time, I would not try to use IRODS to accomplish this, even if it were possible. IRODS is not primarily an identity or access management solution. If you need federated identities and group management, leverage infrastructure designed to provide them.

 

iRODS native federation between zones is “pairwise”, which leads directly to an O(N^2) management problem when setting up and maintaining keys (you _do_ rotate your keys, don’t you?). Kerberos has also had this ability since the early 90s and this management complexity is the most often cited reason that Kerberos federations do not take off. At least Kerberos also has the ability to set up “transitive hierarchies”. Over the years systems like Active Directory and FreeIPA/IdM have sprung up around Kerberos to manage these transitive hierarchies, as well as define and manage groups. iRODS can map foreign credentials onto it’s own set of users via the KRB or GSI plugins, but it doesn’t/can’t import group information from this common store. iRODS has an authentication plugin interface but not an authorization plugin interface.

 

Thinking ahead: iRODS is one application among potentially many, which could use authorization instruments like “groups”. Most applications have their own set of roles, permissions, and assignment of same to users; which they then use to decide what the user is allowed to do. Most of these apps store their authorization data in their own database offline, which keeps the central identity store from piling up the junk data from every app ever stood up by the organization, and avoids the situation where two of these uncoordinated apps want to use the same elements differently. There is potentially an argument to be made that iRODS should read the group information out of an LDAP store like AD or FreeIPA, but how well that fits just depends on what else the AD/FreeIPA store is used for, and how similar your usage of iRODS is to your usage of the rest of the IT infrastructure at your site. If you’re using iRODS to collaborate externally, but AD to manage internal assets, there’s not likely to be a lot of crossover. Authentication may be it, and then only for the internal users. The moral of this story might be that even if you have AD/FreeIPA managing authentication, some users may find it necessary to stand up a separate LDAP server to centralize groups but isolate iRODS.

 

To summarize my random thoughts: There appears to be a whole spectrum of “disaggregation” desirable under different circumstances. The typical enterprise environment is a closed, standalone, monolithic universe, defining all users, services, workstations, etc. An iRODS zone can be a closed universe. It can also accept identities-but-not-groups from an external, potentially federated source (i.e., Kerberos, GSI, other iRODS zones).  There appear to be at least two paths forward for centralizing group definition and management: 1] Within a cooperatively managed infrastructure, a zone could ingest information from an LDAP/AD/FreeIPA store; or 2] In a cross-organization environment, leverage an existing federation solution like SAML, oAuth2, or a virtual organization as appropriate. Quite a wide variety of use cases could be served via the definition of an authorization plugin interface and the development of a handful of useful plugins.

 

Bryce

--

--
"iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat

---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

[Terrell Russell]

A tremendous conversation - thank you all.   An authorization plugin would be very elegant.   If anyone else has experience with this type of scenario or deployments, please continue to share.

Another setup to consider for today's code is a syncing mechanism with an outside group management system (ala Grouper).  This has been demonstrated at a couple sites and is working smoothly as far as I know.

To answer Adam...

> Terrell, you mentioned that in principle the behaviour sounds appropriate, is there any output I can provide to make this clearer and see if we can get it working?

What I meant was that, in spirit, iRODS could redirect and check the remote group definitions over the federation, but I was not sure if the code offered that at this time (it does not).  The more that I think about it, that could explode in complexity like Bryce has suggested.

I have also re-remembered today that groups cannot be put into groups in iRODS.  This is certainly a limitation, but reduces the possible complexity as well.

So for now, I think it does make sense that:

- both local and remote users can be placed into locally defined groups

- remote groups cannot be used within ACL definitions (like the error says, CAT_INVALID_USER)

Terrell

To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

--

--
"iRODS: the Integrated Rule-Oriented Data-management System; A community driven, open source, data grid software solution" https://www.irods.org
 
iROD-Chat: http://groups.google.com/group/iROD-Chat

---
You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.

To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+unsubscribe@googlegroups.com.

[Adam Carrgilson]

Thank you Terrell, Bryce, John, for each of your input. I'm glad I've stirred up some constructive discussion.

I'd certainly be interested to hear from anyone who has experience of using Grouper and syncing across to their systems.

Many Thanks,
Adam.