[Freeipa-devel] Draft: Read permissions for user

[Simo Sorce]

On Wed, 2014-04-23 at 18:19 +0200, Martin Kosek wrote:
> On 04/23/2014 05:21 PM, Simo Sorce wrote:
> > On Wed, 2014-04-23 at 16:37 +0200, Martin Kosek wrote:
> >> On 04/17/2014 01:45 PM, Petr Viktorin wrote:
> >>> On 04/16/2014 03:41 PM, Simo Sorce wrote:
> >>>> On Wed, 2014-04-16 at 15:08 +0200, Martin Kosek wrote:
> >>>>> On 04/15/2014 04:55 PM, Petr Viktorin wrote:
> >>>>>> Hello,
> >>>>>> At Devconf, we decided what most of the default read permissions should look
> >>>>>> like, but we did not get to user.
> >>>>>> Here is a draft of 4 read permissions. Please comment.
> >>>>>>
> >>>>>>
> >>>>>> Basic info (anonymous):
> >>>>>> [top]
> >>>>>>      objectclass
> >>>>>> [person]
> >>>>>>      cn, sn, description
> >>>>>> [organizationalPerson]
> >>>>>>      title
> >>>>>> [inetOrgPerson]
> >>>>>>      uid
> >>>>>>      displayName, givenName, initials
> >>>>>>      manager
> >>>>>> [inetUser]
> >>>>>>      memberOf
> >>>>>
> >>>>> <== We originally specifically hidden memberOf attribute from anonymous users.
> >>>>> I think we should continue hiding it.
> >>>
> >>> OK
> >>>
> >>>>>> [ipaObject]
> >>>>>>      ipaUniqueID
> >>>>>> [ipaSshUser]
> >>>>>>      ipaSshPubKey
> >>>>>> [ipaUserAuthTypeClass]
> >>>>>>      ipaUserAuthType
> >>>>>> [posixAccount]
> >>>>>>      gecos, gidNumber, homeDirectory, loginShell, uidNumber
> >>>>>>
> >>>>>>
> >>>>>> Details (all authenticated):
> >>>>>> [person]
> >>>>>>      seeAlso, telephoneNumber
> >>>>>> [organizationalPerson]
> >>>>>>      fax, l, ou, st, postalCode, street
> >>>>>>      destinationIndicator, internationalISDNNumber,
> >>>>>> physicalDeliveryOfficeName,
> >>>>>>          postalAddress, postOfficeBox, preferredDeliveryMethod,
> >>>>>>          registeredAddress, teletexTerminalIdentifier, telexNumber,
> >>>>>> x121Address
> >>>>>> [inetOrgPerson]
> >>>>>>      carLicense, departmentNumber, employeeNumber, employeeType,
> >>>>>>          preferredLanguage, mail, mobile, pager
> >>>>>>      audio, businessCategory, homePhone, homePostalAddress, jpegPhoto,
> >>>>>>          labeledURI, o, photo, roomNumber, secretary, userCertificate,
> >>>>>>          userPKCS12, userSMIMECertificate, x500UniqueIdentifier
> >>>>>> [inetUser]
> >>>>>>      inetUserHttpURL, inetUserStatus
> >>>>>> [ipaUser]
> >>>>>>      userClass
> >>>>>
> >>>>> I would personally not divide the attributes as basic and detailed. IMO it is
> >>>>> our artificial distinction and may vary between deployments. Why would we for
> >>>>> example show inetUserHttpURL to authenticated only and ipaSshPublicKey to
> >>>>> everyone?
> >>>
> >>> I thought it would be helpful to have a distinction between what needs
> >>> anonymous read, and what's optional.
> >>
> >> I know, my point was that I would leave this distinction to FreeIPA admins as
> >> the visibility to anonymous/authenticated will depend on their policies. I
> >> would create stricter rules only about attributes we are sure about, like the
> >> ones below.
> >>
> >> If some admin wants to hide some attribute, removing it from our user
> >> permission and adding a user read permission for authenticated users is very
> >> simple, I do not think the second permission needs to be managed.
> >>
> >>>
> >>> I can move individual attributes, of course.
> >>>
> >>>>> My proposal would be to have a permission "Read User Information" for all
> >>>>> attributes above.
> >>>
> >>> This way a paranoid admin would need to go through the attributes one by one to
> >>> decide what needs to stay anonymous and what doesn't. Having two permissions
> >>> makes this easier to tune.
> >>>
> >>> But of course I can merge them.
> >>>
> >>
> >> I am not sure how is that simpler. If admin does not like an attribute being
> >> open for authenticated and not for anonymous, he would need to remove it first
> >> from authenticated permission and add it to anonymous permission.
> >>
> >> I am personally for having all attributes above (except memberOf) open for
> >> anonymous. Rob or Simo, are you OK with it?
> > 
> > I am for exposing them only to authenticated users.
> > 
> > Simo.
> > 
> 
> To clarify - you want to have one permission allowing all attributes above
> (except memberOf) to authenticated users? Note that previously we exposed user
> data to anonymous so it would be a functional change.

I know, we may need to provide another permission admins can use to turn
on anonymous searches for those attributes too.
We may also decide that on upgrade vs new install we retain anonymous
access.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York