Good point Akihiro, although this is not an issue in our case, as the client application which serve the data to end users, collocated with the geode server, so passwords are transmitted with in the cluster and this application is already protected.
I am trying to add authentication to backend geode cluster with SecurityManager. This will make client application need username/password in a config file, trying to encrypt this password. One question I still have is, is there default user names: “cluster”, “data” exist for Geode SecurityManager? Sorry for naive question still trying to understand, with out looking into source code. > On Dec 26, 2017, at 7:09 PM, Akihiro Kitada <[email protected]> wrote: > > Hello Sudhir, > > As far as I know, AuthInitialize is executed at client side. If decrypting > passwords at client side via AuthInitialize, those passwords may be conveyed > to server side with plane text unencrypted format via network, according to > the implementation in AuthInitialize. > > If you don't want to convey those passwords with plain text format via > network, anther way is to de/encrypt passwords at server side SecurityManager > implementation at "authenticate" method. > > Thanks, regards. > > > > -- > Akihiro Kitada | Staff Customer Engineer | +81 80 3716 3736 > Support.Pivotal.io | Mon-Fri 9:00am to 5:30pm JST | 1-877-477-2269 > > > > 2017-12-27 5:04 GMT+09:00 Sudhir Babu Pothineni <[email protected]>: >> Thanks Dan. >> >> Yes I am aware it’s not so secure, I am just trying to meet the company >> policy of not directly hardcode the password in a file, encrypted password >> will be ok :). I will implement the AuthInitialize. >> >> >>> On Dec 26, 2017, at 1:34 PM, Dan Smith <[email protected]> wrote: >>> >>> Hi Sudhir, >>> >>> You can do pretty much anything you want by implementing your own >>> AuthInitialize on the client. The AuthInitialize generates the credentials >>> to send to the server. So for example you could implement an AuthInitialize >>> that reads and encrypted password, decrypts it, and sends it to the server. >>> >>> Encrypting your password won't make your system more secure unless you are >>> using something other than a file to store your encryption key though. If >>> your encryption key is just in a file than an attacker just needs to steal >>> that file as well. >>> >>> -Dan >>> >>>> On Tue, Dec 26, 2017 at 10:45 AM, Sudhir Babu Pothineni >>>> <[email protected]> wrote: >>>> It seems password encrypt/decrypt is deprecated Apache geode 1.3. >>>> >>>> What is the alternative if I want hardcore encrypted password in a >>>> configuration file of geode client implementation? >>>> >>>> Thanks >>>> Sudhir >>>> >>>>> On Dec 22, 2017, at 12:35 PM, Jens Deppe <[email protected]> wrote: >>>>> >>>>> Great. Thanks for the feedback about the documentation! >>>>> >>>>> --Jens >>>>> >>>>>> On Fri, Dec 22, 2017 at 10:27 AM, Sudhir Babu Pothineni >>>>>> <[email protected]> wrote: >>>>>> Thanks Jens! Its working. >>>>>> >>>>>> I think in the doc these three parameter should be mentioned together >>>>>> somewhere, Otherwise its not intuitive, although there is lot of >>>>>> description around SecurityManager. >>>>>> >>>>>> security-manager=org.apache.geode.examples.SimpleSecurityManager >>>>>> security-username=admin >>>>>> security-password=xyz1234 >>>>>> >>>>>>> On Fri, Dec 22, 2017 at 10:36 AM, Jens Deppe <[email protected]> wrote: >>>>>>> Hi Sudhir, >>>>>>> >>>>>>> You should find two sample SecurityManagers in the code. >>>>>>> >>>>>>> The first is org.apache.geode.examples.SimpleSecurityManager [1]. This >>>>>>> manager will simply compare the username/password and authenticate if >>>>>>> they match. In addition if the username matches a required permission, >>>>>>> then the request is also authorized. For example, if the credentials >>>>>>> are 'admin/xyz1234' then it will never authenticate. If the credentials >>>>>>> are 'dataRead/dataRead' then the user would be authenticated for all >>>>>>> operations requiring DATA:READ permissions. Although it's simplistic, >>>>>>> this manager is very useful for testing your whole flow and validating >>>>>>> specific permissions for various operations. >>>>>>> >>>>>>> The other SecurityManager provided is >>>>>>> org.apache.geode.examples.security.ExampleSecurityManager [2]. This >>>>>>> manager takes as input a JSON file which maps users -> roles -> >>>>>>> permissions. The javadoc has examples of using this [3]. >>>>>>> >>>>>>> --Jens >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/examples/SimpleSecurityManager.java >>>>>>> [2] >>>>>>> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java >>>>>>> [3] >>>>>>> http://geode.apache.org/releases/latest/javadoc/org/apache/geode/examples/security/ExampleSecurityManager.html >>>>>>> >>>>>>>> On Fri, Dec 22, 2017 at 7:55 AM, Sudhir Babu Pothineni >>>>>>>> <[email protected]> wrote: >>>>>>>> let me extend my question: >>>>>>>> >>>>>>>> Does Geode has any Default/SimpleSecurityManager implementation? >>>>>>>> >>>>>>>>> On Fri, Dec 22, 2017 at 9:15 AM, Sudhir Babu Pothineni >>>>>>>>> <[email protected]> wrote: >>>>>>>>> I am working on Geode(1.2) authentication. According to the doc, >>>>>>>>> https://geode.apache.org/docs/guide/12/managing/security/implementing_authentication.html >>>>>>>>> >>>>>>>>> I put gfsecurity.properties: >>>>>>>>> security-username=admin >>>>>>>>> security-password=xyz1234 >>>>>>>>> Any other parameters needed? >>>>>>>>> >>>>>>>>> because of some reason Geode working without authentication, >>>>>>>>> gfsecurity.properties is in the class path. I am expecting JMX >>>>>>>>> manager also should work on these credentials. >>>>>>>>> >>>>>>>>> Thanks for the help >>>>>>>>> Sudhir >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >
