Make authentication simpler

[jgeewax]

What we do today:

final KeyStore keystore = KeyStore.getInstance("PKCS12");
final FileInputStream fis = new FileInputStream("/path/to/key.p12");
keystore.load(fis, "password".toCharArray());
final PrivateKey key = (PrivateKey) keystore.getKey("privatekey", "password".toCharArray());

final AuthConfig ac = AuthConfig.createFor("email@developer.gserviceaccount.com", key);

final DatastoreServiceOptions options = DatastoreServiceOptions.builder()
    .dataset(datasetId)
    .authConfig(ac)
    .build();

final DatastoreService datastore = DatastoreServiceFactory.getDefault(options);

What we'd like to do:

final Credential credential = DatastoreHelper.getServiceAccountCredential(
    "email@developer.gserviceaccount.com", "/path/to/key.p12");
final DatastoreOptions options = DatastoreHelper.getOptionsfromEnv()
  .dataset(datasetId)
  .credential(credential)
  .build();
final Datastore datastore = DatastoreFactory.get().create(options);

[aozarov]

It is much simpler when running in GCP (AE or CE) when we "auto-detect" the dataset and use the instance credentials.

Though we should provide "helpers" for typical boilerplate code, I am a little hesitant to add code that will work in some environment but not in other (e.g. The use of files (and providing a full path) is not going to work on App Engine).

An alternative that may work for all would be to load the key bytes as a resource.

Also, the suggestion above is only going to work when the password for that keystore is fixed (e.g. "notasecret") so I think the helper should provide a way to supply a different password.

As for getDatastoreFromEnv() it is already partially imlemented, though in an implicit way. When DatastoreServiceOptions.Builder#build is called if a dataset was not provided the
DATASTORE_DATASET System property or Environment variable will be considered. We should probably do that also for DATASTORE_NAMESPACE, SERVICE_ACCOUNT, PRIVATE_KEY_FILE, PRIVATE_KEY_PASSWORD (looks like this could be generic for all gcloud services and not tied to datastore).

Also, env/property settings need to be documented (probably in the matching builder's setter or getter..).
BTW, if providing a way to configure auth via system/env properties do you still find much value in the programmatic helper (which is basically a "PrivateKey" helper...)

[aozarov]

Commit a6cae12 is using now the new authkit library and when default are used (no explicit auth config settings) we will follow the gcloud authentication standard which includes using a file referenced by GOOGLE_APPLICATION_CREDENTIALS environment variable. @jgeewax do you still think we need a helper for reading PK12 files in this case?

[aozarov]

ping.

[jgeewax]

Now that we're using a JSON keyfile (right?), I think the simplest and happiest way to get a Datastore instance would be...

final Datastore datastore = DatastoreHelper.getOptionsfromEnv()
  .dataset(datasetId)
  .keyFile("/path/to/keyfile.json") // Optional if you are in GCE or GAE
  .buildDatastore();

Or something similar. Is that crazy?

[aozarov]

Not necessarily. Do we mandate/accept only json file in the other Veneer libraries (rather than also accepting a p12 key file as well)?

I was trying to see if I can extract the service email from the key (some information is there) but wasn't able to do it using the Java APis.

Using a path for a file is nice but java File is not accessible on all platform and also does not cover all options (e.g. it could be provided as a bundled resource). This is why I leave it for the user to construct the Key (as described above - we could actually have that as snippet as an example in the specific Auth config class javadoc).

Another option instead of File would be to accept a stream which is likely to support all various input type.
In that case these questions are still open:

• Do we only support json file (for getting the service email) or should we support both file types.
• Do we only work with keys that uses the default, notasecret, password?

I think we should keep discussion the other suggestion of creating the service directly from the options in #54.

[jgeewax]

Not necessarily. Do we mandate/accept only json file in the other Veneer libraries (rather than also accepting a p12 key file as well)?

Other libraries accept all of the options. Is it crazy to look up the file and check the extension, and then operate differently based on that? If so, then we could offer ... .p12Key('...') and jsonKey('...') right?

I was trying to see if I can extract the service email from the key (some information is there) but wasn't able to do it using the Java APis.

I was under the impression that you can't get the service account e-mail from a p12 key, which was the point of the JSON keyfile (it includes all the information needed).

Using a path for a file is nice but java File is not accessible on all platform and also does not cover all options (e.g. it could be provided as a bundled resource). This is why I leave it for the user to construct the Key (as described above - we could actually have that as snippet as an example in the specific Auth config class javadoc).

That makes sense. So can we simplify the "get a key" process? Maybe a fromFile() method? My concern is that the following piece is super long.

final KeyStore keystore = KeyStore.getInstance("PKCS12");
final FileInputStream fis = new FileInputStream("/path/to/key.p12");
keystore.load(fis, "password".toCharArray());
final PrivateKey key = (PrivateKey) keystore.getKey("privatekey", "password".toCharArray());
final AuthConfig ac = AuthConfig.createFor("email@developer.gserviceaccount.com", key);

Another option instead of File would be to accept a stream which is likely to support all various input type.

I really like that idea! See my note above about the different forms of auth. The most common will be JSON, the next would be p12 -- nothing stopping us from having multiple "set the key for this builder" methods where the user tells us what kind of key is in the stream.

Do we only work with keys that uses the default, notasecret, password?

I believe so. Currently (AFAIK) there's no way to create a key with a custom password.

[aozarov]

@jgeewax do you think we can close this issue now?

Change #180 does not make it easier to load a pkcs12 file but does make it simpler to work with a json file. See #179 for more details about why we chose only to simplify the json way.

[jgeewax]

@mziccard Can you summarize for me what the auth experience is like in gcloud-java world?

For example, if I want to be explicit about my keyfile and project ID, and get an entity from Datastore in gcloud-node, I do:

var config = {
  projectId: 'grape-spaceship-123',
  keyFilename: '/path/to/keyfile.json'
};

var gcloud = require('gcloud')(config);
var dataset = gcloud.datastore.dataset();
var entity = dataset.get(dataset.key(['Product', 123]));

(see http://googlecloudplatform.github.io/gcloud-node/#/authentication)

If I wanted to do similarly with Java (let's say I just wanted to get an entity from Datastore), what would that code look like (the explicit version)?