> >> Hello Foreman and Katello,
> >> I'd like to start discussion about future of user management in
> >> katello/foreman/signo trio. As you probably noticed Signo currently serve
> >> only
> >> for authentication purpose. It does not know any information about user
> >> that is trying to log in. In fact it asks Katello or LDAP (or Kerberos
> >> soon) whether given credentials are valid.
> >> This means that we cannot create users on fly at the moment. This is
> >> especially
> >> annoying when you use LDAP because you have to login into Katello using
> >> old
> >> way so the user is created in Katello DB (which creates him in Foreman DB
> >> as well).
> >> We could make Signo load more info from auth backends (we need email at
> >> least)
> >> and serve it to apps so they can create users. I'm not sure how this
> >> would
> >> work with Kerberos - there is no email for principal.
> >> Or we take a bigger step and can move users to Signo. Signo would then be
> >> a
> >> primary database of users. In future Signo would take user CRUD
> >> functionality.
> >> We could then use dynflow for user propagation to Katello and Foreman. At
> >> the same time we could make Signo a single place where user roles would
> >> be defined.
> >> Since Katello and Foreman have different roles sets, Signo would define
> >> some generic roles and any system could translate them into its own
> >> roles. Assigning organizations etc. should remain in apps.
> >> Ivan, could you please describe pros of having roles in Signo as we
> >> discussed it?
> > Basically, we have this kind of issues right now:
> > https://bugzilla.redhat.com/show_bug.cgi?id=967583
> > I have permissions to do something in Katello (such as changeset
> > promotion), as part of orchestration, something in Foreman needs to be
> > done but Foreman refused to do that because the user doesn't have the
> > permissions on Foreman side.
> > On the API level, we could proably solve it by making the calls from
> > Katello "almighty", bypassing the permissions checks, as we do it with
> > Pulp. But it wouldn't solve the problems in accessing the UI. So the
> > options are:
> > 1) manage user permissions manually on both places - sucks on many levels
> > 2) synchronize the user changes between Katello and Foreman: when I change
> > something in Katello user permissions, corresponding changes are
> > performed
> > in the orchestration to reflect that in Foreman. This might work, but
> > Katello would be the one responsible for the consistency and mapping
> > and it
> > would be dependent on the roles that are defined in Foreman. On the
> > other
> > side, the Foreman wouldn't know that somebody else is depending on it,
> > which might cause some serious troubles when changing it.
> > 3) since we have signo already here for SSO, it seems like good fit
> > for other user-related actions. How it could work:
> > a. in Signo, we define the users (or connect it to LDAP), and assign
> > roles to them (optionally mapped to LDAP groups). Signo itself wouldn't
> > know what permissions the roles have. So in signo, there would be
> > something like
> > user | contexts | roles
> > ---------------------------------------------
> > admin | | admin
> > peter | ACME | content_management
> > marry | EMEA | provision
> > john | | content_management,provision
> > b. In Katello/Foreman, instead of mapping the subsystem roles to users
> > directly,>
> > the Katello/Foreman roles would be mapped to the Signo roles
> > (ideally 1:1).
> > so for example, for content_management Signo role, a role in Katello
> > would exist allowing changesets provisioning. In Foreman, the
> > content_management would be mapped to role allowing creation of new
> > environments.
> > c. Today, when user logs in into Katello, Katello looks at it's roles
> > and determines>
> > the permissions based on that.
> > With this change, when user logs in, Katello asks signo what Signo
> > roles the user has (similarly to LDAP groups today), and uses the
> > mapping between Signo roles and Katello roles. From the Katello
> > roles, it determines what he/she can/can't do.>
> > So in short: user <-> roles mapping happens in Signo, roles <->
> > permissions mapping happens in the Katello/Foreman.
> > The task for the integration would be to pre-define the roles in Signo
> > and mapping to permissions in Katello and Foreman, so that if someone
> > has some role in Signo, it will let him/her do all the things in the
> > subsystems, that this role requires.>
> > Are there any other options that I didn't mentioned? I like the 3),
> > because it reduces the amount of information that Katello and Foreman
> > (and perhaps other systems) need to know about each other and there would
> > be a neutral place for users management in Signo.
> > Of course, all this would be optional, keeping the Users <-> roles mapping
> > option there when running Katello/Foreman standalone.
> Is the issue that the calling system wants to createa user record, and
> needs more data to do it? I assume email address is the main pain point
Exactly. Sorry I should have been more descriptive.
> If we assume that sign can pass back all the data needed to create
> a user (username, email, roles) then could the pattern be:
> 1) Call signo to get auth
> 2) if auth, and I dont know about the user, call signo to get full on
> user data? Create user locally? Something akin to .
> That way, signo is still a sso brotocol.
Yes. But the problem is not in a way of serving email attribute, but in
fetching in first place. In case of kerberos, Signo does not know where to get
user email (maybe it could ask every enabled backend that can store such
When we get that information (from any backend) we would save it to Signo
local DB. This means we create a new DB of users and I'd like to have only one
that is used primarily. Signo seems to be a natural choice for this.
On Thursday 20 of June 2013 07:56:42 Bryan Kearney wrote:
> On 06/20/2013 05:32 AM, Ivan Necas wrote:
> > ----- Original Message -----
Having said that, it would be great to have a common usr/role model… so
perhaps this gets broken out into a common engine/module with both use.