Difference between revisions of "OpenIDConnectWithApache"
|Line 109:||Line 109:|
== Work in progress ==
== Work in progress ==
Revision as of 15:38, 7 November 2016
Softwares used in this guide
- RT 4.4.1 - Apache - mod_auth_openidc (an Apache module that does all the OpenIDC work) - CentOS 7
You can find it on Github here.
You can get the latest release here.
sudo apt-get update sudo apt-get install libapache2-mod-auth-openidc a2enmod auth_openidc service apache2 restart
CentOS 7 installation
Get the links for the latest centos .rpm releases of cjose and mod_auth_openidc in the link above. You may also need to find a centos .rpm for hiredis - remember to expand the tab for the OS of your choice (CentOS 7 in this case).
yum install https://github.com/pingidentity/mod_auth_openidc/releases/download/v2.1.0/cjose-0.4.1-1.el7.centos.x86_64.rpm yum install http://dl.fedoraproject.org/pub/epel/7/x86_64/h/hiredis-0.12.1-1.el7.x86_64.rpm yum install https://github.com/pingidentity/mod_auth_openidc/releases/download/v2.1.0/mod_auth_openidc-2.1.0-1.el7.centos.x86_64.rpm
Now the mod_auth_openidc module should be installed.
Signing up with an OpenID Connect Provider
To authenticate users, your server needs to be able to talk to someone they trust to provide user identities. In this guide, we will use Google as our OpenID Connect Provider — almost everyone has a Google account. To be able to use Google's authentication services, you will need to visit their Developer console.
1. Find the Google+ API 2. If you click on it, there should be a little header saying you need to create a project. Click the Create Project button and proceed through the setup 3. You will be brought back to the Google+ API screen. On this page, press the Enable button near the top 4. In the left navigation pane, go to Credentials 5. Press the Create Credentials dropdown and select OAuth client ID 6. Configure the consent screen 7. Next, it should ask you to select an application type, pick Web application 8. Give your app a name and don't fill out the other blanks unless you know what they're going to be set up to already 9. There should be a popup telling you what your client ID and secret are — these will be needed later.
Now you have to piece everything together. You can read the mod_auth_openidc Documentation or Wiki pages to set everything up if you'd like, but I'll be providing a step-by-step procedure as well.
So, you're going to have to put some Apache config code somewhere to get mod_auth_openidc to start actually doing things.
For my environment, this is the path to my .conf file:
If you don't have a conf.d folder or some other problem, you can put the Apache config code at the end of your default Apache config file. For my environment, this is the path:
Whatever you choose to do, here are the basic settings that you will need to integrate Google's Sign-In with Request Tracker:
Note: In this setup, RT is found on localhost
# This is the link that Google uses to introduce itself and tell your server it's trustworthy OIDCProviderMetadataURL https://accounts.google.com/.well-known/openid-configuration # The credentials you were presented in the Google Dev Console OIDCClientID a1b2c3d4e5f-j8f91083j0981j02909kd408tu.apps.googleusercontent.com OIDCClientSecret as98jtg981jk02k0a # Must match exactly with Authorized redirect URI in your Google Dev Console OIDCRedirectURI http://localhost/oauth2callback # Set this to whatever you want OIDCCryptoPassphrase anypasswordhere # This will set the environment variable REMOTE_USER to the user's email address instead of the default setting OIDCRemoteUserClaim email OIDCScope "openid email" <Location /> AuthType openid-connect Require valid-user LogLevel debug # If you want debug messages </Location>
Configuring Request Tracker
In your RT_SiteConfig.pm file
Set( $WebRemoteUserAuth, 1 ); Set( $WebFallbackToRTLogin, 1);
At this point, clear your mason cache with
sudo rm -rf path_to_rt/var/mason_data/obj
and restart your webserver.
Now when you visit your Request Tracker, you should immediately be prompted to login with Google — or if you're already logged in to your Google account, your Google email address will be checked against RT's user database. That means if you want RT to grant access to
firstname.lastname@example.org, there must exist an RT user with the name
email@example.com. Otherwise, RT will display a page saying that you are unauthorized and since we set
WebFallbackToRTLogin to 1, you will also have a link that will bring you to RT's default login page.
If you intend to use only the basic configuration, you will need to change how the default RT menu Logout button works. By default, it will log you out of RT, but it will not log you out of your Google account. Because of that, when you logout and get redirected to the login page, the Google email address you used to sign in will be authenticated against RT's database again and you'll be logged back in — making it basically impossible to logout.
Optional Google Sign-In
If you'd like to use Google Sign-In side-by-side RT's default login system — instead of Google Sign-In first and deferring to RT's login system on failure — you will need to add some configuration options to your .conf file and add a Google Sign-In link to RT's login page.
Work in progress
More will be added and elaborated when time permits.