> On 19 Jan 2021, at 03:40, Gary Windham <windh...@arizona.edu> wrote:
> 
> Thanks for the reply, WIlliam. We are using Internet2's Grouper (which 
> synchronizes group memberships to our 389 DS) to create a "chain" of groups 
> that are being used to implement a COVID-19 testing compliance policy at the 
> University of Arizona. One of these groups contains users who have had a test 
> with a positive result in the last 90 days. Since that is personal health 
> information, we didn't want the "isMemberOf" value containing that group to 
> be visible, except to a particular set of users.

You may find it's safer in this case to sync any PHI to either an isolated or 
seperate directory, or to use a seperate attribute indicating the test 
positivity that can have strict access controls placed upon it. 

> 
> However, since sending my original email, we found a workaround -- 
> fortunately, the end group in this "chain" is the only one we really need to 
> sync to 389 DS, so we were able to omit the other groups (including the PHI 
> one) from the sync process.

I'm glad you found a solution still,

Hope I was able to help, 

> 
> Thanks again,
> ---Gary
> 
> --
> Gary Windham
> Principal Enterprise Systems Architect
> University Information Technology Services
> The University of Arizona
>  
> Email: windh...@arizona.edu
> Office: +1 520 626 5981
> 
> 
> On Sun, Jan 17, 2021 at 5:11 PM William Brown <wbr...@suse.de> wrote:
> External Email
> 
> 
> > On 16 Jan 2021, at 05:17, Gary Windham <windh...@email.arizona.edu> wrote:
> > 
> > Hi all,
> > 
> > We're running 389-Directory/1.3.9.0 B2018.304.1940.
> > 
> > Is it possible via ACIs to restrict read/search permission on attributes 
> > with a particular value?
> > 
> > My use case is that we have an "isMemberOf" attribute in our directory, and 
> > we have some group memberships that are of a sensitive nature. I would like 
> > to have all "isMemberOf" attribute values *except* for these sensitive ones 
> > readable/searchable to all authenticated user DNs, and the "sensitive" ones 
> > only readable/searchable by a particular user DN.
> > 
> > Any ideas? From reading the Red Hat directory server ACI documentation, I 
> > can't find a way to do this.
> 
> No, I don't think it's possible. Access controls are based on "which 
> attributes you can/can't see", rather than "you can see these attributes 
> except these values within them". 
> 
> I think that in this case, the possible solutions would be to have a 
> isMemberOfSensitive seperate to the isMemberOf, but that may break many other 
> integrations.
> 
> An important question of course, is why are some group memberships sensitive? 
> What is it you are trying to achieve? 
> 
> > 
> > Thanks in advance,
> > --Gary
> > --
> > Gary Windham
> > Principal Enterprise Systems Architect
> > University Information Technology Services 
> > The University of Arizona
> >  
> > Email: windh...@arizona.edu
> > Office: +1 520 626 5981
> > 
> > _______________________________________________
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> 
> —
> Sincerely,
> 
> William Brown
> 
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
> 

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

Reply via email to