← Back to team overview

canonical-ci-engineering team mailing list archive

jenkins logins from sso

 

A discussion on #ci mentioned (see irclogs.canonical.com for details):

  <dobey> oh. s-jenkins doesn't use sso for accounts?
   
  <vila> dobey: bah, forgot about it, I *did* know how to use it
         http://babune.ladeuil.net:24842/ :-)


Or more precisely for vcs nuts:

  http://bazaar.launchpad.net/~bzr-buildbot-net-dev/bzr-buildbot-net/trunk/revision/246?start_revid=246

which tell us (go click master/config.xml ;) that this has been working
since jenkins version 1.414 on 2011-06-09 ;)

  <vila> dobey: maaah, it's dead simple IIRC, openid plugin and
         http://babune.ladeuil.net:24842/configureSecurity/ access
         control: open sso, url = https://login.launchpad.net.
         Done.
   
  <vila> dobey: thanks for the reminder, I'll discuss it with the team

  <cjohnston> I thought we were going to eventually use ldap

  <retoaded> vila, to some degree it is based on ldap

  <retoaded> vila, I have no idea if it includes lp teams or not


So, once this plugin is installed, ~all that remains to be configured in
jenkins is role <-> lp team and boom you get login and access rights
defined for any new user.

- ~canonical-ci-engineering -> admin (we may want a more restricted team
  but you get the idea)
- ~canonical -> can rebuild
- ~landing-team -> can build

are just a few examples.

If we also start to split our big jenkins into smaller ones, it also
become easier to dedicate a whole jenkins (or 3) to a specific team.

I know we want to use some IS solution to manage ssh keys (among other
things) for the ubuntu user accounts but I don't think all our users
need such accounts.

So for the vast majority of users we get instant setup and long term
access management while keeping only the role management and assignment
to lp teams.

Sounds like a good deal no ?

Some famous founder project related people may even consider it a good
thing that we use a canonical asset for that !

Any concern, feedback or should we just use that as an early target for
some ci on ci (testing the few features we care about here, role
creation, roles access configuration, typical user operations (register,
run job)) ?

       Vincent


Follow ups