ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Bosco Durai <bo...@apache.org>
Subject Re: Users & Certificates
Date Wed, 04 May 2016 16:52:34 GMT
Emails are no long used in Ranger. I feel, we should disable all validations for email. If
it is quick for you, do you want to quickly remove the validation and upload the patch to
be committed?

Thanks

Bosco





On 5/4/16, 9:02 AM, "Bryan Bende" <bbende@gmail.com> wrote:

>Ramesh,
>
>I am working off the master branch, just pulled latest code from about an
>hour ago.
>
>Thanks,
>
>Bryan
>
>
>On Wed, May 4, 2016 at 11:50 AM, Ramesh Mani <rmani@hortonworks.com> wrote:
>
>> Bryan,
>>
>> Which version of the ranger you are trying this?
>>
>> Thanks,
>> Ramesh
>>
>> On 5/4/16, 8:22 AM, "Bryan Bende" <bbende@gmail.com> wrote:
>>
>> >Sure I will create a JIRA about the validation of the usernames.
>> >
>> >I was able to get the user sync running with the file source and
>> >encountered the following... I created a file usergroups.csv based off
>> >
>> https://cwiki.apache.org/confluence/display/RANGER/File+Source+User+Group+
>> >Sync+process
>> >:
>> >
>> >"bob",
>> >"john",
>> >"cn=bbende,dc=example,dc=org",
>> >
>> >When the user sync process runs it gets:
>> >
>> >016-05-04 17:01:28,318 [http-bio-6080-exec-6] INFO
>> > org.apache.ranger.biz.UserMgr (UserMgr.java:1140) - create:bob@localhost
>> >2016-05-04 17:01:28,318 [http-bio-6080-exec-6] INFO
>> > org.apache.ranger.biz.UserMgr (UserMgr.java:1150) - Invalid email
>> >address:bob@localhost
>> >2016-05-04 17:01:28,319 [http-bio-6080-exec-6] INFO
>> > org.apache.ranger.common.RESTErrorUtil (RESTErrorUtil.java:64) - Request
>> >failed. SessionId=13, loginId=rangerusersync, logMessage=Please provide
>> >valid email address.
>> >javax.ws.rs.WebApplicationException
>> >at
>> >org.apache.ranger.common.RESTErrorUtil.createRESTException(RESTErrorUtil.j
>> >ava:55)
>> >at
>> >org.apache.ranger.common.RESTErrorUtil.createRESTException(RESTErrorUtil.j
>> >ava:310)
>> >at
>> >org.apache.ranger.biz.UserMgr.createDefaultAccountUser(UserMgr.java:1151)
>> >
>> >From looking at the code it looks like the email address gets created by
>> >taking the username and adding the hostname detected
>> >from InetAddress.getLocalHost().getCanonicalHostName():
>> >
>> https://github.com/apache/incubator-ranger/blob/8614032c909dd5599fedc35c8f
>> >4b80f71b3a950d/ugsync/src/main/java/org/apache/ranger/unixusersync/process
>> >/PolicyMgrUserGroupBuilder.java#L782
>> >
>> >Is there a recommended approach to make this work?
>> >Seems like validation on the REST endpoint would need to be relaxed, or we
>> >need a way to provide the email address in the file.
>> >
>> >Thanks,
>> >
>> >Bryan
>> >
>> >
>> >On Wed, May 4, 2016 at 1:45 AM, Gautam Borad <gborad@gmail.com> wrote:
>> >
>> >> >
>> >> > >For #1, I wasn't able to add a raw DN as a user through the Ranger
>> >>UI. I
>> >> > think the '=' character violates the validation rules, but maybe that
>> >>is
>> >> an
>> >> > easy change to allow it.
>> >> > Yes, this should be an easy change. Can you create a JIRA. I feel,
in
>> >>the
>> >> > long run we should probably take some of these rules by property. It
>> >> might
>> >> > already by. Gautam, are you aware of it?
>> >>
>> >>
>> >> Bosco, we currently dont have this feature of taking the rules by
>> >>property.
>> >> However it sounds like a good idea to do so! Thanks.
>> >>
>> >>
>> >> On Wed, May 4, 2016 at 6:25 AM, Don Bosco Durai <bosco@apache.org>
>> >>wrote:
>> >>
>> >> > >I think the file upload could be the best option for now, depending
>> >>if
>> >> > there are any issues with special characters.
>> >> >
>> >> >
>> >>
>> >>
>> https://cwiki.apache.org/confluence/display/RANGER/File+Source+User+Group
>> >>+Sync+process
>> >> >
>> >> >
>> >> > >For #1, I wasn't able to add a raw DN as a user through the Ranger
>> >>UI. I
>> >> > think the '=' character violates the validation rules, but maybe that
>> >>is
>> >> an
>> >> > easy change to allow it.
>> >> > Yes, this should be an easy change. Can you create a JIRA. I feel,
in
>> >>the
>> >> > long run we should probably take some of these rules by property. It
>> >> might
>> >> > already by. Gautam, are you aware of it?
>> >> >
>> >> > >For #2, I think the issue would be that two users could have the
>> >>same CN
>> >> > from different organizations, and so the full the DN is really the
>> >>unique
>> >> > identifier.
>> >> > Yes, it is possible. Note, if you will be doing any Hadoop related
>> >> > operations behalf of the user, then you will will get into other
>> >>issues.
>> >> If
>> >> > you are, then you will have to tokenize it to unix friendly name
>> >> >
>> >> > >For grouping, I see that RangerAccessRequest allows setting the
user
>> >> > groups.
>> >> > Grouping will help you minimize the number of policies. If you feel,
>> >>we
>> >> > can break the DN and create logical groups, and if that works, then
it
>> >> will
>> >> > easy for the admins to configure policies. Essentially, you could have
>> >> each
>> >> > level as a group. And give group level permissions...
>> >> > "OU=Apache NiFi, O=Apache, L=Santa Monica, ST=CA, C=US², "O=Apache,
>> >> > L=Santa Monica, ST=CA, C=US², "L=Santa Monica, ST=CA, C=US², Š
>> >> >
>> >> >
>> >> >
>> >> > >One scenario is when two NiFi instances communicate directly over
a
>> >> > secure connection, we would need to create a policy in Ranger for the
>> >>DN
>> >> of
>> >> > one instance to give access to the resource being accessed on the
>> >>other
>> >> > instance.
>> >> > This would be easy. You might need very few policy line items and it
>> >>will
>> >> > be easy to manage.
>> >> >
>> >> > >We could also have scenarios where regular users are issued
>> >>certificates
>> >> > and accessing the NiFi UI with those certificates.
>> >> > If these are human users, then there might be more policies/line
>> >>items,
>> >> > but still manageable. If each device is an user, then you should
>> >>consider
>> >> > creating the policies using REST API.
>> >> >
>> >> > Thanks
>> >> >
>> >> > Bosco
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On 5/3/16, 7:15 AM, "Bryan Bende" <bbende@gmail.com> wrote:
>> >> >
>> >> > >Hi Bosco,
>> >> > >
>> >> > >Thanks for the response. Could you elaborate on Ranger's file upload
>> >> > >feature? Is this done through the REST API?
>> >> > >I think the file upload could be the best option for now, depending
>> >>if
>> >> > >there are any issues with special characters.
>> >> > >
>> >> > >For #1, I wasn't able to add a raw DN as a user through the Ranger
>> >>UI. I
>> >> > >think the '=' character violates the validation rules, but maybe
>> >>that is
>> >> > an
>> >> > >easy change to allow it.
>> >> > >
>> >> > >For #2, I think the issue would be that two users could have the
>> >>same CN
>> >> > >from different organizations, and so the full the DN is really
the
>> >> unique
>> >> > >identifier.
>> >> > >
>> >> > >For grouping, I see that RangerAccessRequest allows setting the
user
>> >> > >groups. I think the issue is that on the NiFi side when we
>> >>authenticate
>> >> a
>> >> > >user who presents a certificate,
>> >> > >we don't have knowledge of a group for that user, so we wouldn't
know
>> >> what
>> >> > >to set on the access request.
>> >> > >
>> >> > >For some general background, NiFi has a pluggable authentication
>> >> mechanism
>> >> > >and currently has three mechanisms: 2-way SSL, LDAP, and Kerberos....
>> >> > 2-way
>> >> > >SSL is always enabled when running a secured instance.
>> >> > >One scenario is when two NiFi instances communicate directly over
a
>> >> secure
>> >> > >connection, we would need to create a policy in Ranger for the
DN of
>> >>one
>> >> > >instance to give access to the resource being accessed on the other
>> >> > >instance.
>> >> > >We could also have scenarios where regular users are issued
>> >>certificates
>> >> > >and accessing the NiFi UI with those certificates.
>> >> > >
>> >> > >Thanks,
>> >> > >
>> >> > >Bryan
>> >> > >
>> >> > >
>> >> > >On Tue, May 3, 2016 at 1:06 AM, Don Bosco Durai <bosco@apache.org>
>> >> wrote:
>> >> > >
>> >> > >> From the Ranger point of view it is just any other user, but
we
>> >>have
>> >> to
>> >> > >> check whether Ranger supports all the characters valid in
the DN.
>> >> > >>
>> >> > >> The interesting part is how we classify this user. Will it
be in
>> >> LDAP/AD
>> >> > >> or if it is device, then it might not be. So we have a couple
of
>> >> > options:
>> >> > >>
>> >> > >> 1. Add the DN to Ranger in the raw format and give permissions
to
>> >>it
>> >> > using
>> >> > >> policy. It will have usability issue in UI.
>> >> > >> 2. Map the DN to simple name. E.g. In Hadoop, it could be
the CN or
>> >> UID
>> >> > >> attribute. Or sAMAccountName from AD. In your case, both
>> >>provisioning
>> >> to
>> >> > >> Ranger and NiFiRangerAuthorizer has to do the same conversion.
>> >> > >>
>> >> > >> Do you think, #2 is possible for you?
>> >> > >>
>> >> > >> Regardless, you could use Ranger¹s file upload feature to
load the
>> >> > users.
>> >> > >> I feel, we might get into special character issues like space
or
>> >> comma.
>> >> > I
>> >> > >> think, we can fix this if required.
>> >> > >>
>> >> > >> Another suggestion is, can we have group concept for these
DN?
>> >> > >>
>> >> > >> Thanks
>> >> > >>
>> >> > >>
>> >> > >> Bosco
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> On 5/2/16, 9:43 AM, "Bryan Bende" <bbende@gmail.com>
wrote:
>> >> > >>
>> >> > >> >Hello,
>> >> > >> >
>> >> > >> >If an application is authenticating users with 2-way SSL,
how
>> >>would
>> >> > those
>> >> > >> >users be entered into Ranger in order to define policies
for
>> >>them? or
>> >> > is
>> >> > >> >that not really a supported scenario?
>> >> > >> >
>> >> > >> >For example, if I authenticate to my application with
a
>> >>certificate,
>> >> > the
>> >> > >> >identity passed to the plugin will be the DN from the
certificate
>> >> like:
>> >> > >> >
>> >> > >> >CN=localhost, OU=Apache NiFi, O=Apache, L=Santa Monica,
ST=CA,
>> >>C=US
>> >> > >> >
>> >> > >> >So I was trying to see if it was possible to define a
policy for
>> >>that
>> >> > >> user.
>> >> > >> >
>> >> > >> >Thanks,
>> >> > >> >
>> >> > >> >Bryan
>> >> > >>
>> >> > >>
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards,
>> >> Gautam.
>> >>
>>
>>


Mime
View raw message