On su, 25 marras 2018, Alex Corcoles via FreeIPA-users wrote:
Hi,
On Sun, 2018-11-25 at 14:48 +0200, Alexander Bokovoy wrote:
1) SAML
>
> As I recall, there's Ipsilon and Keycloak. Ipsilon is "dead" and
> Keycloak is the way to go, right?
No. Both Ipsilon and Keycloak are healthy and kicking well. Ipsilon
is
what Fedora Project's FAS service is built upon.
Oh, but the RHEL 7.5 release notes say:
Red Hat Access plug-in for IdM is discontinued
The Red Hat Access plug-in for Identity Management (IdM) was removed
in Red Hat Enterprise Linux 7.3. During the update, the redhat-
access-plugin-ipa package is automatically uninstalled. Features
previously provided by the plug-in, such as Knowledgebase access and
support case engagement, are still available through the Red Hat
Customer Portal. Red Hat recommends to explore alternatives, such as
the redhat-support-tool tool.
The Ipsilon identity provider service for federated single sign-on
The ipsilon packages were introduced as Technology Preview in Red Hat
Enterprise Linux 7.2. Ipsilon links authentication providers and
applications or utilities to allow for single sign-on (SSO).
Red Hat does not plan to upgrade Ipsilon from Technology Preview to a
fully supported feature. The ipsilon packages will be removed from
Red Hat Enterprise Linux in a future minor release.
Red Hat has released Red Hat Single Sign-On as a web SSO solution
based on the Keycloak community project. Red Hat Single Sign-On
provides greater capabilities than Ipsilon and is designated as the
standard web SSO solution across the Red Hat product portfolio.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.5_release_notes/chap-red_hat_enterprise_linux-7.5_release_notes-deprecated_functionality
and there have been no commits to the Ipsilon repo in a year...
RHEL is not shipping Ipsilon, that's all what above is explained.
Fedora Project is using it but Fedora's FAS service is deployed on RHEL
and it is rock-solid for the functionality they use. There are 15 pull
requests open, so clearly some work is ongoing. If you are interested,
talk to ipsilon developers.
> However, Keycloak setup is not trivial, correct? Running CentOS
> there
> is no straightforward way to install and integrate it with a
> FreeIPA
> domain, correct?
Not correct either. With current Keycloak release there is a detailed
(and fairly simple) instruction:
https://www.keycloak.org/docs/latest/server_admin/index.html#_sssd
For OpenShift-based deployment Fraser did a blog:
https://frasertweedale.github.io/blog-redhat/posts/2017-09-04-keycloak-openshift.html
I mean it still requires a sizable amount of elbow grease. I think
there is no systemd unit file, it doesn't come as an RPM which can be
easily upgraded, etc.
I think Java applications have a bit different way of distribution, so
Keycloak is more oriented for that than a pure system service.
Even if Ipsilon is phased out I think I'll try again. IIRC, I had an
issue doing a test run, read about Keycloak being the future and gave
up quickly. RHEL 7 is still good for a few years, so maybe I have an
alternative solution on RHEL 8 when it dies.
Keycloak's benefits are in ability to integrate well with existing
Java-based web applications. It becomes part of the established
infrastructure there and makes SSO screens tuned to the design of the
app, giving better user experience.
> 2) SSO
>
> What is the special sauce for users using a browser on an IPA-
> joined
> system to log in to apps without even seeing a login form? SPNEGO?
>
> I'm using mod_auth_gssapi for some apps, having httpd do the
> authentication and forward it through REMOTE_USER, but it doesn't
> do
> the magic. There are some hints on mod_auth_gssapi's docs, but
> nothing
> really clear.
Clients need to be configured to accept and allow Negotiate
authentication. My recommendation (and the one we applied to browsers
in
Fedora) is to set your
network.negotiate-auth.trusted-uris
to
https://
The logic in Firefox is to match a substring from what is in
network.negotiate-auth.trusted-uri setting. Setting it to allow
negotiate on any HTTPS site is enough. If the site offers Negotiate
authentication, browser will attempt to obtain a Kerberos service
ticket
to that site. If that is not possible (KDC doesn't know about the
host),
Negotiate authentication will not continue and the site will never
know
a Negotiate authentication was attempted but failed.
That's how my Firefox in FC28-29 was configured OOB, but while it works
perfectly on the IPA web interface, an httpd site which has:
<Location />
AuthType GSSAPI
AuthName "Kerberos Login"
GssapiCredStore keytab:/etc/xxx.keytab
GssapiBasicAuth On
require valid-user
</Location>
does perfect validation, but no SSO.
mod_auth_gssapi produces a cookie that should be served back to the
client. If client returns the same cookie, mod_auth_gssapi will handle
SSO for the client automatically.
> 3) How should you deliver apps?
>
> Suppose you are a web app developer and you want to deliver a web
> application which can easily integrate with FreeIPA. What's the
> most
> comfortable option you can give? (assuming, for instance, that you
> want
> the SSO magic sauce). Is there any difference between apps that
> will
> run on the FreeIPA's domain owner's systems or third party apps?
I don't think there is any difference. From the perspective of a
client
browser, authentication happens between the client and the SSO host,
not
the web app. So strictly speaking, only SSO host needs to be
enrolled. A
client system needs to be able to operate with Kerberos to obtain the
tickets automatically for SSO but it is not necessary as user could
enter his/her credentials instead.
How SSO framework does authenticate the web app is totally separate.
For example, I run HackMD app with authentication handled against my
own FreeIPA via Ipsilon. HackMD uses OAuth OpenID Connect against
Ipsilon and is totally disconnected from FreeIPA view of the users,
their authentication, etc. All it knows is what Ipsilon OAuth OpenID
Connect assertion tells about the user.
I was thinking whether it was preferrable to target REMOTE_USER and
have httpd do the auth or use something like OAuth, which I guess is
preferrable.
It depends on what you want to achieve within your app. OAuth or SAML
give you details in the assertion. These details from FreeIPA side can
help application to make an access control decision -- whether user
belongs to certain groups, etc. If your apps don't need that, a simple
REMOTE_USER should be fine. For Ipsilon/Keycloak, though, it is
preferable to rely on OAuth or SAML between IdP and the web app. This
simply gives more information about the user than you'd get through
REMOTE_USER.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
