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