[Freeipa-users] Web app integration
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
--
___
{~._.~}
( Y )
()~*~() mail: alex at corcoles dot net
(_)-(_) http://alex.corcoles.net/
___
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
[Freeipa-users] Re: Web app integration
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.
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.
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
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.
You can achieve the same with Chrome/Chromium.
$ cat /etc/chromium/policies/managed/negotiate.json
{
"AuthServerWhitelist": "*",
}
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.
--
/ 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
[Freeipa-users] Re: Web app integration
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... > > 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. 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. > > 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: AuthType GSSAPI AuthName "Kerberos Login" GssapiCredStore keytab:/etc/xxx.keytab GssapiBasicAuth On require valid-user does perfect validation, but no SSO. > > 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
[Freeipa-users] Re: Web app integration
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.
--
___
{~._.~}
( Y )
()~*~() mail: alex at corcoles dot net
(_)-(_) http://alex.corcoles.net/
___
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
[Freeipa-users] Re: Installation Error in step: Configuring the web interface (httpd)
On 11/17/18 10:29 PM, c.monty--- via FreeIPA-users wrote:
Hi,
the installation fails in step
Configuring the web interface (httpd) - [19/21]: starting httpd
The error details are here:
[root@vm200-freeipa ~]# tail /var/log/ipaserver-install.log
File "/usr/lib/python3.7/site-packages/ipaserver/install/service.py",
line 497, in start
self.service.start(instance_name, capture_output=capture_output,
wait=wait)
File "/usr/lib/python3.7/site-packages/ipaplatform/base/services.py",
line 302, in start
skip_output=not capture_output)
File "/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line
573, in run
p.returncode, arg_string, output_log, error_log
2018-11-17T21:12:05Z DEBUG The ipa-server-install command failed,
exception: CalledProcessError: CalledProcessError(Command
['/bin/systemctl', 'start', 'httpd.service'] returned non-zero exit
status 1: 'Job for httpd.service failed because the control process
exited with error code.\nSee "systemctl status httpd.service" and
"journalctl -xe" for details.\n')
2018-11-17T21:12:05Z ERROR CalledProcessError(Command ['/bin/systemctl',
'start', 'httpd.service'] returned non-zero exit status 1: 'Job for
httpd.service failed because the control process exited with error
code.\nSee "systemctl status httpd.service" and "journalctl -xe" for
details.\n')
2018-11-17T21:12:05Z ERROR The ipa-server-install command failed. See
/var/log/ipaserver-install.log for more information
[root@vm200-freeipa ~]# tail /var/log/httpd/error_log
[Sat Nov 17 22:12:05.818963 2018] [ssl:emerg] [pid 3948:tid
139946752436480] SSL Library Error: error:0D0680A8:asn1 encoding
routines:asn1_check_tlen:wrong tag
[Sat Nov 17 22:12:05.818970 2018] [ssl:emerg] [pid 3948:tid
139946752436480] SSL Library Error: error:0D08303A:asn1 encoding
routines:asn1_template_noexp_d2i:nested asn1 error
[Sat Nov 17 22:12:05.818975 2018] [ssl:emerg] [pid 3948:tid
139946752436480] SSL Library Error: error:0D0680A8:asn1 encoding
routines:asn1_check_tlen:wrong tag
[Sat Nov 17 22:12:05.818981 2018] [ssl:emerg] [pid 3948:tid
139946752436480] SSL Library Error: error:0D07803A:asn1 encoding
routines:asn1_item_embed_d2i:nested asn1 error (Type=RSAPrivateKey)
[Sat Nov 17 22:12:05.818994 2018] [ssl:emerg] [pid 3948:tid
139946752436480] SSL Library Error: error:04093004:rsa
routines:old_rsa_priv_decode:RSA lib
[Sat Nov 17 22:12:05.818999 2018] [ssl:emerg] [pid 3948:tid
139946752436480] SSL Library Error: error:0D0680A8:asn1 encoding
routines:asn1_check_tlen:wrong tag
[Sat Nov 17 22:12:05.819004 2018] [ssl:emerg] [pid 3948:tid
139946752436480] SSL Library Error: error:0D07803A:asn1 encoding
routines:asn1_item_embed_d2i:nested asn1 error (Type=PKCS8_PRIV_KEY_INFO)
[Sat Nov 17 22:12:05.819008 2018] [ssl:emerg] [pid 3948:tid
139946752436480] AH02311: Fatal error initialising mod_ssl, exiting. See
/etc/httpd/logs/error_log for more information
[Sat Nov 17 22:12:05.819011 2018] [ssl:emerg] [pid 3948:tid
139946752436480] AH02564: Failed to configure encrypted (?) private key
ipa.biszumbitterenen.de:443:0, check /var/lib/ipa/private/httpd.key
AH00016: Configuration Failed
How can I fix this error and continue installation?
THX
Hi,
which version of python{2|3}-pyasn1 is installed on your system (and
which OS)? There were known issues on CentOS depending on the pyasn1
version (FreeIPA install fails on CentOS 7 if pyasn1 0.3.2 is installed
[1]).
HTH,
flo
[1] https://pagure.io/freeipa/issue/7103
___
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
___
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
[Freeipa-users] Re: How to add host with subdomain local..de
On 11/19/18 12:22 AM, 74cmonty via FreeIPA-users wrote: Hi, I completed installation using the recommended FQHN ipa..de of FreeIPA server. How can I add a client host configured with sub-domain local..de? Hi, if FreeIPA server was installed with embedded DNS, you can add a DNS zone for local..de (see [1]), have the client point to FreeIPA master DNS (configure /etc/resolv.conf) and simply run ipa-client-install --domain .de --realm .DE. HTH, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/managing-master-dns-zones THX ___ 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 ___ 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
[Freeipa-users] Re: Web app integration
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: AuthType GSSAPI AuthName "Kerberos Login" GssapiCredStore keytab:/etc/xxx.keytab GssapiBasicAuth On require valid-user 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
