Hi,
I've read:
https://www.freeipa.org/page/Web_App_Authentication
, but there is some stuff that is not clear to me.
1) SAML
As I recall, there's Ipsilon and Keycloak. Ipsilon is "dead" and Keycloak is the way to go, right?
However, Keycloak setup is not trivial, correct? Running CentOS there is no straightforward way to install and integrate it with a FreeIPA domain, correct?
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.
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?
Cheers,
Álex
On Sun, 25 Nov 2018, Alex Corcoles via FreeIPA-users wrote:
Hi,
I've read:
https://www.freeipa.org/page/Web_App_Authentication
, but there is some stuff that is not clear to me.
- 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.
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-opens...
- 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.
You can achieve the same with Chrome/Chromium.
$ cat /etc/chromium/policies/managed/negotiate.json { "AuthServerWhitelist": "*", }
- 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.
Hi,
On Sun, 2018-11-25 at 14:48 +0200, Alexander Bokovoy wrote:
- 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/htm...
and there have been no commits to the Ipsilon repo in a year...
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-opens...
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.
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.
- 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.
- 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.
Cheers,
Álex
On Sun, 2018-11-25 at 18:51 +0100, Alex Corcoles wrote:
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.
Actually just gave it a whirl and it worked nearly out of the box*. Installation is even more painless than FreeIPA's.
I'll play a bit more with Ipsilon. I think Keycloak is fancier but Ipsilon might give me what I want with less effort.
Cheers,
Álex
* /etc/pki/tls/private/localhost.key and /etc/pki/tls/certs/localhost.crt for some reason were borked and I had to regenerate them on a clean instance.
On su, 25 marras 2018, Alex Corcoles via FreeIPA-users wrote:
Hi,
On Sun, 2018-11-25 at 14:48 +0200, Alexander Bokovoy wrote:
- 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/htm...
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-opens...
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.
- 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.
- 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.
Hi,
On Sun, 2018-11-25 at 22:28 +0200, Alexander Bokovoy wrote:
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.
Cool, just sent an email to their list:
https://lists.fedorahosted.org/archives/list/ipsilon@lists.fedorahosted.org/...
The list looks a bit dead and while there are PRs, there is not much recent activity, however I'll try that first. Little activity sometimes means stable and working!
I did a quick POC and set up automated provisioning of a working Ipsilon instance integrated to my FreeIPA doamin in a few lines of configuration management- looks like Keycloak would be significantly more involved, so if Ipsilon is alive and well and given that the benefits you mention for Keycloak are not so compelling for my use case, it seems to be a better fit for me.
Thanks!
Álex
On Sun, Nov 25, 2018 at 06:51:36PM +0100, Alex Corcoles via FreeIPA-users wrote:
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.
OTOH, creating the systemd unit file is not super complex either: https://matthew-beliveau.github.io/How-to-Setup-Keycloak/ https://matthew-beliveau.github.io/Keycloak-and-FreeIPA/
On Mon, 2018-11-26 at 09:24 +0100, Jakub Hrozek via FreeIPA-users wrote:
On Sun, Nov 25, 2018 at 06:51:36PM +0100, Alex Corcoles via FreeIPA- users wrote:
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.
OTOH, creating the systemd unit file is not super complex either: https://matthew-beliveau.github.io/How-to-Setup-Keycloak/ https://matthew-beliveau.github.io/Keycloak-and-FreeIPA/
Yeah, sure, but compared to installing an RPM and running a command like FreeIPA and Ipsilon, it's a lot.
I'm doing a lot of automated provisioning nowadays and even simple instructions such as that mean it's significantly more effort to set up, so I tend to favor a lot stuff which is install RPM, alter configuration as needed and go.
Cheers,
Álex
Massive thread necromancy but...
On Sun, 2018-11-25 at 12:21 +0100, Alex Corcoles wrote:
- 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.
Playing around with my Ipsilon install I found the problem of my setup. I was doing:
ipa service-add nagios/my.host
but I needed to use:
ipa service-add HTTP/my.host
apparently if you don't name it HTTP, the keytab works but doesn't do SSO.
Cheers,
Álex
On Sun, 10 Mar 2019, Alex Corcoles via FreeIPA-users wrote:
Massive thread necromancy but...
On Sun, 2018-11-25 at 12:21 +0100, Alex Corcoles wrote:
- 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.
Playing around with my Ipsilon install I found the problem of my setup. I was doing:
ipa service-add nagios/my.host
but I needed to use:
ipa service-add HTTP/my.host
apparently if you don't name it HTTP, the keytab works but doesn't do SSO.
Yes, the naming of Kerberos principals is more or less historical. All browsers only request service tickets to HTTP/<hostname> principal. If you expect browsers to utilize GSSAPI, your target Kerberos service principal must be HTTP/.. according to https://tools.ietf.org/html/rfc4559 section 4.1.
If you are using custom protocol, it is up to client and server to establish a common agreement how the principal name should be constructed.
On Sun, Mar 10, 2019 at 7:25 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Yes, the naming of Kerberos principals is more or less historical. All browsers only request service tickets to HTTP/<hostname> principal. If you expect browsers to utilize GSSAPI, your target Kerberos service principal must be HTTP/.. according to https://tools.ietf.org/html/rfc4559 section 4.1.
Ah, thanks Alexander, that is actually very useful, as now I would like to get the negotiation working across a reverse proxy (which I think is not possible in the way I'd like to- I took it to https://github.com/modauthgssapi/mod_auth_gssapi/issues/201 , but I'm not sure that's the best place).
BTW, I think this tidbit is not mentioned in the howtos in the wiki. I think the wiki is not publicly editable, right? Could someone make a visible note about that (the link to the RFC is quite interesting)?
Cheers,
Álex
On ma, 11 maalis 2019, Alex Corcoles via FreeIPA-users wrote:
On Sun, Mar 10, 2019 at 7:25 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Yes, the naming of Kerberos principals is more or less historical. All browsers only request service tickets to HTTP/<hostname> principal. If you expect browsers to utilize GSSAPI, your target Kerberos service principal must be HTTP/.. according to https://tools.ietf.org/html/rfc4559 section 4.1.
Ah, thanks Alexander, that is actually very useful, as now I would like to get the negotiation working across a reverse proxy (which I think is not possible in the way I'd like to- I took it to https://github.com/modauthgssapi/mod_auth_gssapi/issues/201 , but I'm not sure that's the best place).
BTW, I think this tidbit is not mentioned in the howtos in the wiki. I think the wiki is not publicly editable, right? Could someone make a visible note about that (the link to the RFC is quite interesting)?
Can you point me to a page where you want it added?
Well, looking at it I think it's already well documented at:
https://www.freeipa.org/page/Web_App_Authentication#Kerberos
So maybe it doesn't need any change, although a link to the RFC and being more explicit about the HTTP/ thing would be better, I guess... but now I feel that the documentation is OK and I was just dumb :-p
On Mon, Mar 11, 2019 at 11:22 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On ma, 11 maalis 2019, Alex Corcoles via FreeIPA-users wrote:
On Sun, Mar 10, 2019 at 7:25 PM Alexander Bokovoy abokovoy@redhat.com wrote:
Yes, the naming of Kerberos principals is more or less historical. All browsers only request service tickets to HTTP/<hostname> principal. If you expect browsers to utilize GSSAPI, your target Kerberos service principal must be HTTP/.. according to https://tools.ietf.org/html/rfc4559 section 4.1.
Ah, thanks Alexander, that is actually very useful, as now I would like to get the negotiation working across a reverse proxy (which I think is not possible in the way I'd like to- I took it to https://github.com/modauthgssapi/mod_auth_gssapi/issues/201 , but I'm not sure that's the best place).
BTW, I think this tidbit is not mentioned in the howtos in the wiki. I think the wiki is not publicly editable, right? Could someone make a visible note about that (the link to the RFC is quite interesting)?
Can you point me to a page where you want it added?
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
freeipa-users@lists.fedorahosted.org
-
Alex Corcoles -
Alexander Bokovoy -
Jakub Hrozek