Hi Hasini, I thing it is good to have both properties "false" by default. The reason because, if the user need to enable those features, user may need to do few other configuration changes like pointing correct authorization server url , credential etc ... .IMO it is ok to ask advanced user to edit those properties instead of simple user who won't use this features.
I saw you have added new property call "TLS.api.server.port" . is there any reason you can't use apiserver.port property for this? Thanks, Shameera. On Wed, Jul 8, 2015 at 12:13 PM Hasini Gunasinghe <[email protected]> wrote: > Hi all, > > I just wanted to notify about some of the security related configuration > changes merged with Airavata master. Please let me know if you have any > objections. > > 1). Following two properties in airavata-server.properties controls if the > OAuth token validation is performed upon method invocation and the if the > Airavata server is exposed over TLS, respectively. > > - api.secured > - TLS.enabled > > Default value for both those two parameters in the > airavata-server.properties shipped in the distribution is 'true' (i.e: > token validation is performed upon method invocation and the airavata > server is hosted only over TLS.) > > When you write unit tests, integration tests without security, you can set > the parameter values to 'false' and proceed as usual. > > 2). Default key store (airavata.jks) and trust store > (client_truststore.jks) are shipped with the distribution which are located > in airavata_home/bin directory. Password of both of them are 'airavata' and > the client_truststore.jks contains the public certificates of Airavata and > WSO2 IS. These are used in the SSL handshakes. > Production deployment should replace them with organizational keystore and > trust store. > I will add this information to documentation as well. > > Thanks, > Hasini. > -- Shameera Rathnayaka
