ranger-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sailaja Polavarapu <spolavar...@hortonworks.com>
Subject Re: Users & Certificates
Date Wed, 04 May 2016 21:18:26 GMT
After following the code in the ranger admin for adding portal users, following are some of
the observations to be considered:
1. In the DB level email field can be null
2. In UserMrg.java, if the emailAddress (from the request) is null or empty, we are generating
a randomUID and assigning using that email address to create or update portal user. Of course
in this case we are not doing any validation checks.

One suggestion I have here is, instead of removing the validation checks for email address
-
1. Remove auto population of email address in the ranger usersync for File source (and other
sync sources if needed)
2. Remove auto population of email address with randomUID in ranger admin code.
3. Do validation only when email address is not null & not empty.

Thanks,
Sailaja.




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

>Ok I noticed it wasn't required in the UI so that makes sense.
>
>Let me see what I can do, I'll create a JIRA.
>
>On Wed, May 4, 2016 at 12:52 PM, Don Bosco Durai <bosco@apache.org> wrote:
>
>> 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