5:40 a.m.
In Ipsilon, we recently (OK, about a year ago) added an authorisation
stack. This allows us to control, Ipsilon-side, which users are
permitted to log into which service providers. Our authorisation plugin
functions are currently fairly limited, basically using user group
membership to control which service providers a user has access to. One
of the things we'd like to support is using FreeIPA's HBAC rules rather
than user attributes directly. In my opinion, this makes it much more
obvious what's going on and fits in better with FreeIPA's architecture.
There're a few options that have come up in discussions around this on
#ipsilon and #sssd:
1) Treat each service provider as a new service in FreeIPA. The most
basic HBAC rule would then be "<user> can log into <ipsilon server> via
service <service provider>". Ipsilon can easily do a PAM_ACCT_MGMT PAM
call (either using a PAM library, or by talking to SSSD directly using
the PAM socket) with the appropriate service name. SSSD will then
permit or deny the check based on the HBAC rules. This is nice and
simple, but the permitted length / characters of service names could
have a potential limit on what service providers can be authorised this
way.
2) Ipsilon fetches HBAC rules from FreeIPA and processes them itself.
This requires duplication of the HBAC processing logic in Ipsilon
(although I believe the python bindings for libipa_hbac deal with most
of the heavy lifting there), and LDAP connectivity to the FreeIPA
server(s), along with the appropriate login credentials. Ipsilon would
need to have any appropriate retry / failover logic. With this method,
we can create service providers as hosts in FreeIPA, and HBAC rules
would be "<user> can log into <service provider> via service saml2"
(or
openidc, etc).
3) Ipsilon uses the FreeIPA JSON-RPC API to call the hbactest API. This
moves the HBAC check to the FreeIPA server, where the logic already
exists. This requires Ipsilon to have access to the FreeIPA API and the
appropriate login credentials. Moving the HBAC checks into FreeIPA
itself has load implications for the IPA servers. Again, this would
permit HBAC rules of the style "<user> can log into <service provider>
via saml2".
4) Add support to SSSD for performing HBAC checks for arbitrary FreeIPA
hosts. This lets SSSD deal with connections to FreeIPA, including
authentication and failover, which it's already doing. Some mechanism
would be needed for Ipsilon to pass the "destination host" to SSSD for
use in the HBAC check rather than the local IPA hostname.
All of these options assume that there's an HBAC rule to permit the user
to log in to the Ipsilon server itself via the "ipsilon" service, which
we require now.
Considering I'm writing this mail, it'll come as no surprise that I'm
most interested in option 4. SSSD only fetches HBAC rules from FreeIPA
that affect the local host (unless the legacy src host option is
enabled), so there'd need to be an option to enable fetching all rules
instead. I'm not clear if there's a PAM attribute that could be used to
pass the remote host name to SSSD for the check, so my thought was to
add HBAC functionality to the infopipe (Ipsilon can already use the
Infopipe for fetching user attributes). My first thought is something
like an org.freedesktop.sssd.infopipe.HBAC DBus interface with an
Evaluate method that takes hostname, username, and service name, and
returns a boolean.
So, basically, if I were to work up patches to implement this option,
would they have a chance of being accepted into SSSD? In the meantime
we'll probably look at implementing one of option 2 or 3, but the SSSD
option is appealing to me in the longer term.
Cheers.
--
HJ
8:10 a.m.
On Tue, Jun 27, 2017 at 11:40:37AM +0100, Howard Johnson wrote:
In Ipsilon, we recently (OK, about a year ago) added an authorisation
stack.
This allows us to control, Ipsilon-side, which users are permitted to log
into which service providers. Our authorisation plugin functions are
currently fairly limited, basically using user group membership to control
which service providers a user has access to. One of the things we'd like
to support is using FreeIPA's HBAC rules rather than user attributes
directly. In my opinion, this makes it much more obvious what's going on
and fits in better with FreeIPA's architecture.
There're a few options that have come up in discussions around this on
#ipsilon and #sssd:
1) Treat each service provider as a new service in FreeIPA. The most basic
HBAC rule would then be "<user> can log into <ipsilon server> via
service
<service provider>". Ipsilon can easily do a PAM_ACCT_MGMT PAM call (either
using a PAM library, or by talking to SSSD directly using the PAM socket)
with the appropriate service name. SSSD will then permit or deny the check
based on the HBAC rules. This is nice and simple, but the permitted length
/ characters of service names could have a potential limit on what service
providers can be authorised this way.
2) Ipsilon fetches HBAC rules from FreeIPA and processes them itself. This
requires duplication of the HBAC processing logic in Ipsilon (although I
believe the python bindings for libipa_hbac deal with most of the heavy
lifting there)
correct. I think this would be the second-quickest path forward.
, and LDAP connectivity to the FreeIPA server(s), along with
the appropriate login credentials. Ipsilon would need to have any
appropriate retry / failover logic. With this method, we can create service
providers as hosts in FreeIPA, and HBAC rules would be "<user> can log into
<service provider> via service saml2" (or openidc, etc).
3) Ipsilon uses the FreeIPA JSON-RPC API to call the hbactest API. This
moves the HBAC check to the FreeIPA server, where the logic already exists.
This requires Ipsilon to have access to the FreeIPA API and the appropriate
login credentials. Moving the HBAC checks into FreeIPA itself has load
implications for the IPA servers. Again, this would permit HBAC rules of
the style "<user> can log into <service provider> via saml2".
I think this is the quickest path forward.
4) Add support to SSSD for performing HBAC checks for arbitrary FreeIPA
hosts. This lets SSSD deal with connections to FreeIPA, including
authentication and failover, which it's already doing. Some mechanism would
be needed for Ipsilon to pass the "destination host" to SSSD for use in the
HBAC check rather than the local IPA hostname.
All of these options assume that there's an HBAC rule to permit the user to
log in to the Ipsilon server itself via the "ipsilon" service, which we
require now.
Considering I'm writing this mail, it'll come as no surprise that I'm most
interested in option 4.
I see two problems with option 4:
1) what interface to use, which is discussed below
2) sssd_be currently authenticates using the host keytab. In order
to learn what host groups apply to a certain host, IIRC the hosts's
memberof attribute is read. I'm not sure if a host can read another
host's groups and if it currently does, whether it would continue
working. But maybe this is something that could be solved by tuning
the permissions on the server side?
SSSD only fetches HBAC rules from FreeIPA that
affect the local host (unless the legacy src host option is enabled), so
there'd need to be an option to enable fetching all rules instead. I'm not
clear if there's a PAM attribute that could be used to pass the remote host
name to SSSD for the check, so my thought was to add HBAC functionality to
the infopipe (Ipsilon can already use the Infopipe for fetching user
attributes). My first thought is something like an
org.freedesktop.sssd.infopipe.HBAC DBus interface with an Evaluate method
that takes hostname, username, and service name, and returns a boolean.
There were requests to implement authentication over the D-bus interface
in the past and we were quite reluctant to them, but IIRC that was
because PAM handles prompting for the secrets, passing auth tokens and
it's just well battle-tested.
But I don't see the same issues with an authorization call.
I would prefer another interface than infopipe (authzpipe?), but in
general, as long as the interface is restricted to authorization and not
authentication, I don't see an inherent issue.
>
> So, basically, if I were to work up patches to implement this option, would
> they have a chance of being accepted into SSSD? In the meantime we'll
> probably look at implementing one of option 2 or 3, but the SSSD option is
> appealing to me in the longer term.
>
> Cheers.
>
> --
> HJ
> _______________________________________________
> sssd-devel mailing list -- sssd-devel(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-devel-leave(a)lists.fedorahosted.org
6:14 a.m.
On ti, 27 kesä 2017, Jakub Hrozek wrote:
On Tue, Jun 27, 2017 at 11:40:37AM +0100, Howard Johnson wrote:
> In Ipsilon, we recently (OK, about a year ago) added an authorisation stack.
> This allows us to control, Ipsilon-side, which users are permitted to log
> into which service providers. Our authorisation plugin functions are
> currently fairly limited, basically using user group membership to control
> which service providers a user has access to. One of the things we'd like
> to support is using FreeIPA's HBAC rules rather than user attributes
> directly. In my opinion, this makes it much more obvious what's going on
> and fits in better with FreeIPA's architecture.
>
> There're a few options that have come up in discussions around this on
> #ipsilon and #sssd:
>
> 1) Treat each service provider as a new service in FreeIPA. The most basic
> HBAC rule would then be "<user> can log into <ipsilon server> via
service
> <service provider>". Ipsilon can easily do a PAM_ACCT_MGMT PAM call
(either
> using a PAM library, or by talking to SSSD directly using the PAM socket)
> with the appropriate service name. SSSD will then permit or deny the check
> based on the HBAC rules. This is nice and simple, but the permitted length
> / characters of service names could have a potential limit on what service
> providers can be authorised this way.
>
> 2) Ipsilon fetches HBAC rules from FreeIPA and processes them itself. This
> requires duplication of the HBAC processing logic in Ipsilon (although I
> believe the python bindings for libipa_hbac deal with most of the heavy
> lifting there)
correct. I think this would be the second-quickest path forward.
> , and LDAP connectivity to the FreeIPA server(s), along with
> the appropriate login credentials. Ipsilon would need to have any
> appropriate retry / failover logic. With this method, we can create service
> providers as hosts in FreeIPA, and HBAC rules would be "<user> can log
into
> <service provider> via service saml2" (or openidc, etc).
>
> 3) Ipsilon uses the FreeIPA JSON-RPC API to call the hbactest API. This
> moves the HBAC check to the FreeIPA server, where the logic already exists.
> This requires Ipsilon to have access to the FreeIPA API and the appropriate
> login credentials. Moving the HBAC checks into FreeIPA itself has load
> implications for the IPA servers. Again, this would permit HBAC rules of
> the style "<user> can log into <service provider> via saml2".
I think this is the quickest path forward.
>
> 4) Add support to SSSD for performing HBAC checks for arbitrary FreeIPA
> hosts. This lets SSSD deal with connections to FreeIPA, including
> authentication and failover, which it's already doing. Some mechanism would
> be needed for Ipsilon to pass the "destination host" to SSSD for use in
the
> HBAC check rather than the local IPA hostname.
>
> All of these options assume that there's an HBAC rule to permit the user to
> log in to the Ipsilon server itself via the "ipsilon" service, which we
> require now.
>
> Considering I'm writing this mail, it'll come as no surprise that I'm
most
> interested in option 4.
I see two problems with option 4:
1) what interface to use, which is discussed below
2) sssd_be currently authenticates using the host keytab. In order
to learn what host groups apply to a certain host, IIRC the hosts's
memberof attribute is read. I'm not sure if a host can read another
host's groups and if it currently does, whether it would continue
working. But maybe this is something that could be solved by tuning
the permissions on the server side?
I think we currently have no limitation on
memberof attribute access for
authorized users. E.g. host/.. principal bind to LDAP gives you access
to memberof attribute without any limitation.
We are going to introduce a special type of groups where membership
reading would be limited to some conditions but this would not be
relevant to HBAC, at least from my current understanding of the
situation. This is to support organizational groups, not host-based
access rights.
So I think option 4 is OK from the server perspective. Note also that
option 3 needs an authenticated access too and might just use either
ipsilon's principal (HTTP/ipsilon.hostname) or some specialized one, or
host/ principal as well. This is not going to be much different to
option 4 with regards to authentication details.
> SSSD only fetches HBAC rules from FreeIPA that
> affect the local host (unless the legacy src host option is enabled), so
> there'd need to be an option to enable fetching all rules instead. I'm not
> clear if there's a PAM attribute that could be used to pass the remote host
> name to SSSD for the check, so my thought was to add HBAC functionality to
> the infopipe (Ipsilon can already use the Infopipe for fetching user
> attributes). My first thought is something like an
> org.freedesktop.sssd.infopipe.HBAC DBus interface with an Evaluate method
> that takes hostname, username, and service name, and returns a boolean.
There were requests to implement authentication over the D-bus interface
in the past and we were quite reluctant to them, but IIRC that was
because PAM handles prompting for the secrets, passing auth tokens and
it's just well battle-tested.
But I don't see the same issues with an authorization call.
I would prefer another interface than infopipe (authzpipe?), but in
general, as long as the interface is restricted to authorization and not
authentication, I don't see an inherent issue.
Yep. I guess the whole story is
about extending SSSD cache handling to
support storing multiple hosts' HBAC rules details.
--
/ Alexander Bokovoy
9:29 a.m.
Cheers for the feedback.
On 2017-06-28 12:14, Alexander Bokovoy wrote:
We are going to introduce a special type of groups where membership
reading would be limited to some conditions but this would not be
relevant to HBAC, at least from my current understanding of the
situation. This is to support organizational groups, not host-based
access rights.
I guess at worst for this we might need a new set of
role/privilege/permission that would allow viewing of all memberOf
attributes.
On ti, 27 kesä 2017, Jakub Hrozek wrote:
> There were requests to implement authentication over the D-bus
> interface
> in the past and we were quite reluctant to them, but IIRC that was
> because PAM handles prompting for the secrets, passing auth tokens and
> it's just well battle-tested.
Yeah, that absolutely makes sense.
> But I don't see the same issues with an authorization call.
Excellent :)
> I would prefer another interface than infopipe (authzpipe?), but
in
> general, as long as the interface is restricted to authorization and
> not
> authentication, I don't see an inherent issue.
Would the authzpipe be another interface provided by sssd_ifp, or would
you want another process (say, sssd_azp) to provide it?
I guess then if I were to start working up some patches, I wouldn't be
wasting everyone's time? :)
--
HJ
9:39 a.m.
On Wed, Jun 28, 2017 at 03:29:02PM +0100, Howard Johnson wrote:
Cheers for the feedback.
On 2017-06-28 12:14, Alexander Bokovoy wrote:
> We are going to introduce a special type of groups where membership
> reading would be limited to some conditions but this would not be
> relevant to HBAC, at least from my current understanding of the
> situation. This is to support organizational groups, not host-based
> access rights.
I guess at worst for this we might need a new set of
role/privilege/permission that would allow viewing of all memberOf
attributes.
> On ti, 27 kesä 2017, Jakub Hrozek wrote:
> > There were requests to implement authentication over the D-bus
> > interface
> > in the past and we were quite reluctant to them, but IIRC that was
> > because PAM handles prompting for the secrets, passing auth tokens and
> > it's just well battle-tested.
Yeah, that absolutely makes sense.
> > But I don't see the same issues with an authorization call.
Excellent :)
> > I would prefer another interface than infopipe (authzpipe?), but in
> > general, as long as the interface is restricted to authorization and
> > not
> > authentication, I don't see an inherent issue.
Would the authzpipe be another interface provided by sssd_ifp, or would you
want another process (say, sssd_azp) to provide it?
I think reusing the same responder is OK, but I would prefer another
interface. I don't know if we have any issues supporting multiple
interfaces from the same process, but if we do, it's a bug and should be
fixed.
I guess then if I were to start working up some patches, I wouldn't be
wasting everyone's time? :)
Could you please write up a design page first?
Check e.g.
https://docs.pagure.org/SSSD.sssd/design_pages/non_posix_support.html
The source can be found in our docs repo:
https://pagure.io/SSSD/docs
here:
https://pagure.io/SSSD/docs/blob/master/f/design_pages/non_posix_support.rst
(submitting a PR against the docs repo is enough)
9:50 a.m.
On 2017-06-28 15:39, Jakub Hrozek wrote:
I think reusing the same responder is OK, but I would prefer another
interface. I don't know if we have any issues supporting multiple
interfaces from the same process, but if we do, it's a bug and should
be
fixed.
I think technically the current infopipe API consists of multiple
interfaces, so adding e.g. org.freedesktop.sssd.authzpipe shouldn't be a
problem. I can test that easily enough, though.
Could you please write up a design page first?
Yep, will do. Thanks!
9:43 a.m.
On ke, 28 kesä 2017, Howard Johnson wrote:
Cheers for the feedback.
On 2017-06-28 12:14, Alexander Bokovoy wrote:
>We are going to introduce a special type of groups where membership
>reading would be limited to some conditions but this would not be
>relevant to HBAC, at least from my current understanding of the
>situation. This is to support organizational groups, not host-based
>access rights.
I guess at worst for this we might need a new set of
role/privilege/permission that would allow viewing of all memberOf
attributes.
Correct. Though the way how HBAC rules are evaluated right now by SSSD
assumes we are dealing with POSIX users/groups there, so a subject of
the HBAC check is a user with POSIX group membership. This membership
information is already flattened so that intermediate non-POSIX group
membership is not there anymore because POSIX groups are
non-hierarchical. Given that we would specifically target those
organizational groups for non-POSIX use, I don't think we lose anything
here.
--
/ Alexander Bokovoy
2487
days inactive
2488
days old
sssd-devel@lists.fedorahosted.org
6 comments
3 participants
participants (3)
-
Alexander Bokovoy -
Howard Johnson -
Jakub Hrozek