Signo and shared user management

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?

What do teams think? Ohad, Mike would you support such change?

··· -- Marek

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

··· ----- Original Message ----- > 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?

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.

– Ivan

What do teams think? Ohad, Mike would you support such change?


Marek


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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
here? 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 [1].

That way, signo is still a sso brotocol.

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.

– bk

[1] http://code.google.com/p/lightopenid/wiki/GettingMoreInformation

··· On 06/20/2013 05:32 AM, Ivan Necas wrote: > > > ----- Original Message ----- >> 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.

Guys,

I am having an impression we are trying to build another directory
service here. Why? Foreman/Katello are configured with our
(puppet-based) installer and if you want to integrate those two
projects, why not to add OpenLDAP or any other easy-to-configure
directory service into our installer.

Instead we are trying to find a way to integrate CLI with Signo, but hey
wait - we also need to support Kerberos. So we will implement both.
Please don't get me wrong, maybe I miss a little detail that Signo
brings. Or it's just lack of sleep.

To me it sounds like we are investing resources into something that can
be replaced with including OpenLDAP + KRB in our installer. At the very
beginning, discussion ended up with "we want let users to install
Katello/Foreman without LDAP", but writing our own LDAP does not solve
the issue.

What was blocking us from the embedded OpenLDAP+KRB solution in the
first place?

··· On Thu, Jun 20, 2013 at 09:50:19AM +0200, Marek Hulan wrote: > What do teams think? Ohad, Mike would you support such change?


Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

> >
> >> 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
> here?
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 [1].
>
> 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
attribute).

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.

– bk

[1] http://code.google.com/p/lightopenid/wiki/GettingMoreInformation

Marek

Feeling is right (I have the same), but reality is very different in the
open-source environment. We are not building big monolithic blocks, we
are picking up the best open source technologies, adding features,
fixing and testing in a collaborative way into a product.

One simply cannot throw away a living community and take the code,
rewrite it and turn two projects into one. That's simply not feasible
and we need to live with that.

Integration is not easy, but possible. When done right, it works
seamlessly.

··· On Thu, Jun 20, 2013 at 08:40:15AM -0400, Tom McKay wrote: > As I've mentioned to "those in charge," I feel strongly that the > architecture of having Katello and Foreman as separate code bases is a > mistake. One of the products should "win" and the others' begin to be > folded into it in a nice software engineering sort of way (engines or > such). Signo was a bandaid for single sign on for two separate tools; > can their be serious discussions about the reasons why we would wish > to continue to keep them separate code?


Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

> >
> > 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.
>
> If I understand the table above correctly, the user is the subject,
> the contexts is the object, and roles is the operation that subjects
> can do with objects. Are you sure that objects modelled this way will
> not limit you ery soon. The example shows ACME and EMEA which I assume
> are organizations … but soon you might want environments or systems
> or system groups or repos as objects. To store that relationship, you
> would have to know about those types of objects in Signo and in LDAP.
> Do you really have two-way synchronization of data in mind?

I was thinking about Signo/LDAP saying what roles does the user have and
Katello/Foreman determining the access to the subjects based on the data.

For the other entities acting as object, what about roles in Signo/LDAP such
as 'systems_self_service' meaning the user can only see his/her systems? The
information about what 'owning a system' means would be still in Katello/Foreman.

We could also make the meaning of ACME/EMEA more general, saying it means groups of users.
In subsystems, we would then assign this groups to permissions. Katello/Foreman
would say what groups are available in Signo. Signo would say what users as in those groups.
It's not two-way syncing, as this are two separate operations (provided Katello doesn't store
the info about users <-> roles association and one can't CRUD groups in Signo (just assigning
them to users).

– Ivan

··· ----- Original Message ----- > On Thu, Jun 20, 2013 at 05:32:32AM -0400, Ivan Necas wrote:


Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat

> > What do teams think? Ohad, Mike would you support such change?
>
> Guys,
>
> I am having an impression we are trying to build another directory
> service here. Why? Foreman/Katello are configured with our
> (puppet-based) installer and if you want to integrate those two
> projects, why not to add OpenLDAP or any other easy-to-configure
> directory service into our installer.
>
> Instead we are trying to find a way to integrate CLI with Signo, but hey
> wait - we also need to support Kerberos. So we will implement both.
> Please don't get me wrong, maybe I miss a little detail that Signo
> brings. Or it's just lack of sleep.
>
> To me it sounds like we are investing resources into something that can
> be replaced with including OpenLDAP + KRB in our installer. At the very
> beginning, discussion ended up with "we want let users to install
> Katello/Foreman without LDAP", but writing our own LDAP does not solve
> the issue.

As I described in my previous mail I've just wrote, the issue we're trying
to solve is being able to say, that user has some level of permissions on
one place and guarantee, that in all the subsystems, he will be able to do
that.

Of course, from the Katello/Foreman perspective, it doesn't matter where
the information about user roles come from. The advantage of using Signo
as a provider for this is abstracting what's available in the infrastructure.

I understand this efford more as a front-end level. That doesn't mean
we can't use LDAP as a backend. But we still want a common place to manage
this things. And what backend to use for it is just an implementation detail.

– Ivan

··· ----- Original Message ----- > On Thu, Jun 20, 2013 at 09:50:19AM +0200, Marek Hulan wrote:

What was blocking us from the embedded OpenLDAP+KRB solution in the
first place?


Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman


You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hmm frond-end argument makes sense, without signo it would be just plain
Kerberos or Kerberos via Apache httpd. Not that fancy.

LZ

··· On Thu, Jun 20, 2013 at 05:47:34AM -0400, Ivan Necas wrote: > As I described in my previous mail I've just wrote, the issue we're trying > to solve is being able to say, that user has some level of permissions on > one place and guarantee, that in all the subsystems, he will be able to do > that. > > Of course, from the Katello/Foreman perspective, it doesn't matter where > the information about user roles come from. The advantage of using Signo > as a provider for this is abstracting what's available in the infrastructure. > > I understand this efford more as a front-end level. That doesn't mean > we can't use LDAP as a backend. But we still want a common place to manage > this things. And what backend to use for it is just an implementation detail.


Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

> I am having an impression we are trying to build another directory
> service here. Why? Foreman/Katello are configured with our
> (puppet-based) installer and if you want to integrate those two
> projects, why not to add OpenLDAP or any other easy-to-configure
> directory service into our installer.
>
> Instead we are trying to find a way to integrate CLI with Signo, but hey
> wait - we also need to support Kerberos. So we will implement both.
> Please don't get me wrong, maybe I miss a little detail that Signo
> brings. Or it's just lack of sleep.
This was not the original intention. We want to support any auth backend. LDAP
and Kerberos are the first we want to have. Also we don't want to force Katello
and Foreman to implement all backends we want to support (e.g. Keystone).
Signo main puprpose was to create some kind of authentication proxy. On one
end it support any authentication mechanism on the other end it talks to
Katello/Foreman/whatever using OpenID (on web).

> To me it sounds like we are investing resources into something that can
> be replaced with including OpenLDAP + KRB in our installer. At the very
> beginning, discussion ended up with "we want let users to install
> Katello/Foreman without LDAP", but writing our own LDAP does not solve
> the issue.
I believe in enterprise environment there are existing and custom setups of
LDAP and KRB, we probably don't want force our users to install OpenLDAP and
MIT Kerberos. We could support custom LDAP setup in Katello and Foreman but it
would mean to keep the same code consistent in two separate codebases. Here
comes Signo role.

> What was blocking us from the embedded OpenLDAP+KRB solution in the
> first place?
Using Signo does not prevent us (re)using OpenLDAP and Kerberos at all. It's
just abstraction?

Also Signo could extract some common logic behind user and roles management.
It's probably something that we could achieve using LDAP, but Signo has other
benefits (hopefully visible from what was written above) so why not add it in
there?

··· -- Marek

> > To me it sounds like we are investing resources into something that can
> > be replaced with including OpenLDAP + KRB in our installer. At the very
> > beginning, discussion ended up with "we want let users to install
> > Katello/Foreman without LDAP", but writing our own LDAP does not solve
> > the issue.
> I believe in enterprise environment there are existing and custom setups of
> LDAP and KRB, we probably don't want force our users to install OpenLDAP and
> MIT Kerberos. We could support custom LDAP setup in Katello and Foreman but it
> would mean to keep the same code consistent in two separate codebases. Here
> comes Signo role.

Satellite5 comes with embedded Oracle. It's a "black box" installation
(with limitations of course). And there is an option to setup external
Oracle.

Sometimes you need to force users for the default option, in this case
LDAP+KRB. Or in our case Signo, I assume.

> > What was blocking us from the embedded OpenLDAP+KRB solution in the
> > first place?
> Using Signo does not prevent us (re)using OpenLDAP and Kerberos at all. It's
> just abstraction?
>
> Also Signo could extract some common logic behind user and roles management.
> It's probably something that we could achieve using LDAP, but Signo has other
> benefits (hopefully visible from what was written above) so why not add it in
> there?

I guess my arguments are irrelevant now - as Ivan pointed out, we are
building a SSO frontend. LDAP+KRB does not give you front end basically.

Thanks

··· On Thu, Jun 20, 2013 at 12:11:36PM +0200, Marek Hulan wrote:


Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman