> > >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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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.
