Please provide service accounts

[James Westby]

Hi,

I was just talking to Stuart and Anthony about this, and they told me to file a bug.
I'll do my best to explain what I mean, but feel free to ask for clarification if needed.

From time to time we have to have one service authenticate to another that uses
SSO. For instance, we want to have a bot that talks to Launchpad via the OAUTH-protected
API.

This runs as a non-interactive service, but needs some credentials if it can't do what
it needs to anonymously.

There are two choices here:
  1) Run as one user with the appropriate permissions, for instance the author. This is frequently done for single-person bots, but isn't good when it's a shared service, as it will fall over if e.g. that person leaves the team, and can allow for impersonation if other people have access to the credentials.
  2) Create a service account in SSO (Launchpad). This is an account that is purely there to do this job, and doesn't represent a human being.

Doing the latter involves:

  * Signing up for an account
  * Specifying a valid email address that can be accessed by the team that runs the bot, and not just the person that is setting up the bot.
  * Getting the oauth credentials for that account
  * Setting up the service with those credentials.
  * Keeping the password safe (maybe by discarding it)

This is a headache (particularly the email address and password requirements)

If you want to do something like revoke the credentials and generate new ones
you have to:

  * Log out of Launchpad
  * Log in again using the password from before.
  * Make the needed changes
  * Log back in to your real account

If you threw away the password then that becomes

  * Log out of Launchpad
  * Trigger a password reset of the service account
  * Access the inbox of the email account specified in the account creation
  * Complete the password reset
  * Make the changes
  * Log back in to your real account.

What would be better would be if we could do the following:

  * Create a service account on SSO (Launchpad)
  * Nominate a team who are able to impersonate that account
  * Impersonate the account to get the OAuth credentials.
  * Set the service up the with credentials.

Now any user in the admin team can make any changes that are needed, so the OAuth revoke would be like

  * Log out of Launchpad
  * Log in again, specifying the service account and authenticating as yourself.
  * Make the changes that are needed
  * Log back in to your real account.

Which is much simpler overall.

Obviously this is fairly likely to be an intrusive change, but may be limited to
SSO if e.g. Launchpad can just see these things as regular accounts, though the
lack of an email address may affect that.

My team would likely create a new service account every month or two. I've also seen other
people have to do this (e.g. https://launchpad.net/~package-import)

Thanks,

James

[Stuart Metcalfe (stuartmetcalfe)]

James, thanks for filing the bug. This is a feature we'd like to add one day as it will make using SSO accounts for API users easier to manage and will keep our own personal accounts safer. That said, I don't know when we'll find time to do it as it's a non-trivial change.