> On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > >
Thanks a lot, Bosco, for your meticulous comments! I did a lot of refactoring, to replace unirest with apache httpclient, and to bubble exceptions upward. I welcome your feedback as always! > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetBearerToken.java > > Lines 34 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270179#file2270179line34> > > > > Could we document what this configFile should contain? If it is user > > entered, then can we validate that it has all the fields we are expecting? Done: added description of required elements to the README file, and added validation of the required elements to the HandleSecrets class. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetBearerToken.java > > Lines 44 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270179#file2270179line44> > > > > Does this have sensitive information? If so, we should print in debug > > logs > > Barbara Eckman wrote: > Is that a question? "Should we print in debug logs?" I considered this > along with a Comcast security colleague and decided that putting this warning > in the README file was sufficient: "NOTE that if this code is run with debug > logging enabled, there will be a very high likelihood that sensitive content > will be emitted in the log.". If you don't think it's sufficient, I can > remove printing it in the debug logs, but it seems as though it would be nice > to see what's in there, if an error should occur that involves the file > contents. I have removed the printing to debug log > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetBearerToken.java > > Lines 50 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270179#file2270179line50> > > > > Should strToken = null? So that the caller would know if the request > > failed? > > Barbara Eckman wrote: > I'm not against this, but I already raise an error if the request for > token fails, and execution should halt after that, shouldn't it? Or am I > missing your point? Sorry, my last comment made no sense. I changed strToken's initialization to null. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetBearerToken.java > > Lines 58 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270179#file2270179line58> > > > > Should we check if the post was successfull? E.g. check for HTTP return > > code? Done. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetBearerToken.java > > Lines 63 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270179#file2270179line63> > > > > Instead of doing e.toString(), can we just pass "e" to the logger? So > > the stack trace will be printed? > > Barbara Eckman wrote: > done I refactored to throw exceptions upward. Should I print to logger.error before throwing the exception? > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetBearerToken.java > > Lines 67 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270179#file2270179line67> > > > > Would the response be null if the Unirest.post() throws an Exception? > > We could probably move this code within the try block above Done > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetFromDataFile.java > > Lines 35 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270180#file2270180line35> > > > > Any reason this is class member attribute rather than defining it > > within the method getFromDataFile(). If i t is okay to have it class member > > attribute, then should we worry about multi-thread safety scenarios? Done > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetFromDataFile.java > > Lines 48 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270180#file2270180line48> > > > > We should probably ident this properly. It seems as if though it is > > closing the try block. Done > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetFromURL.java > > Lines 39 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270181#file2270181line39> > > > > What should we do if the GetBearerToken.getBearerToken() fails for any > > reason? I removed most of the try/catches from all classes, and added some thrown exceptions beyond what was already there. All exceptions now bubble up to RangerExternalUserStoreRetriever. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetFromURL.java > > Lines 49 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270181#file2270181line49> > > > > Should return from here or rethrow the exception if the Unirest.get() > > request fails? addressed when refactoring to use apache httpclient library instead of unirest. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > > Lines 34 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270182#file2270182line34> > > > > Any reason we are having this has class static? It seems, line number > > 39 redefines it with the class method? Same the member attribute > > decodedSecrets also Done. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > > Lines 41 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270182#file2270182line41> > > > > Is it secure to print sensitive information? > > Barbara Eckman wrote: > see response to getBearerToken, line 44 I removed debug logging of sensitive info. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > > Lines 50 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270182#file2270182line50> > > > > Is it secure to print sensitive information? > > Barbara Eckman wrote: > see response to getBearerToken, line 44 I removed debug logging of sensitive info. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > > Lines 55 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270182#file2270182line55> > > > > What is the purpose for this method? Is it just to read the entire file > > into a string object? If so, should we use class method like > > File.readString()? I think File.readString() was not introduced until Java 11, but I found this and used it instead: new String(Files.readAllBytes(Paths.get(configFile)))); > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > > Lines 56 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270182#file2270182line56> > > > > To optimize on memory, should we StringBuffer here? I replaced the Scanner-based read with *new String(Files.readAllBytes(Paths.get(configFile)))*. The config files are very small (under 20 lines of json), so I'm inclined to not worry about memory for them. Do you agree? > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > > Lines 59 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270182#file2270182line59> > > > > Can we use closable (try()) here? So that even there is an exception, > > the stream will be closed The readFromFile method's use of Scanner was replaced, as suggested, by the simple *new String(Files.readAllBytes(Paths.get(configFile))))*. Does this obviate the need for closable try()? > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > > Lines 73 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270182#file2270182line73> > > > > Can we use closable here? So that even on exception the stream is > > closed. i used try-with-resources: try ( FileWriter myWriter = new FileWriter(fileName);){ I think that does the same thing, right? > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > > Lines 77 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270182#file2270182line77> > > > > Any reason we are supressing this error? Should we propagate for the > > caller so it can be handled appropriately? Done. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/RangerExternalUserStoreRetriever.java > > Lines 54 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270186#file2270186line54> > > > > Do we need to handle failure to getFromURL() method ? Added thrown exceptions. All exceptions now bubble up to RangerExternalUserStoreRetriever. > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/RangerExternalUserStoreRetriever.java > > Lines 56 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270186#file2270186line56> > > > > Is it okay to ignore this exception? > > Can we also remove the next line? changes to throw exceptions upward made this comment irrelevant, I think.... > On Oct. 7, 2022, 1:30 a.m., Don Bosco Durai wrote: > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/RangerRoleUserStoreRetriever.java > > Lines 76 (patched) > > <https://reviews.apache.org/r/74142/diff/1/?file=2270187#file2270187line76> > > > > Does need to be in the seperate line? done - Barbara ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/74142/#review224760 ----------------------------------------------------------- On Sept. 26, 2022, 7:17 p.m., Barbara Eckman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/74142/ > ----------------------------------------------------------- > > (Updated Sept. 26, 2022, 7:17 p.m.) > > > Review request for ranger and madhan. > > > Bugs: Ranger-3855 > https://issues.apache.org/jira/browse/Ranger-3855 > > > Repository: ranger > > > Description > ------- > > RangerExternalUserStoreRetriever class Ranger-3855 > > Ranger version 3.0.0 provides a means, via a context enricher, to add or > retrieve attributes to the database of users for whom Ranger controls access. > This permits syntax like "Dumbo" in $USER.aliases any Ranger policy > condition, including row and tag filters. This greatly enhances the ability > to provide custom Attribute-based Access Control based on the specific > business needs of one's organization. > > I believe that the original assumption was that such attributes would be > added to AD/LDAP and enter Ranger via regular user sync's. However, this > process does not currently work with Azure AD, which many organizations use. > Neither does it provide timely support for organizations for whom adding each > new attribute to AD would be subject to prolonged scrutiny by overworked > security teams. > > In the spirit of the RangerAdminUserStoreRetriever context enricher, we have > written a RangerExternalUserStoreRetriever class which adds arbitrary > attributes to Ranger users via external API calls, thus freeing additions to > the UserStore from dependency on AD/LDAP. We have also written a > RangerRoleUserStoreRetriever class, which transforms role membership into > user attributes, for ease of use in complex policy conditions. > > > Diffs > ----- > > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetBearerToken.java > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetFromDataFile.java > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/GetFromURL.java > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/HandleSecrets.java > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/LICENSE > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/NOTICE > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/README.md > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/RangerExternalUserStoreRetriever.java > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/RangerRoleUserStoreRetriever.java > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/TokenInputs.java > PRE-CREATION > > agents-common/src/main/java/org/apache/ranger/plugin/contextenricher/externalUserStoreRetrievers/pom.xml > PRE-CREATION > plugin-nestedstructure/README.md ea878f6a2 > > > Diff: https://reviews.apache.org/r/74142/diff/1/ > > > Testing > ------- > > > Thanks, > > Barbara Eckman > >
