Bryan, Which version of the ranger you are trying this?
Thanks, Ramesh On 5/4/16, 8:22 AM, "Bryan Bende" <[email protected]> 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 <[email protected]> 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 <[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. >>
