So, my next project. We have a custom made portal with an own user database. We wanted to use a Wiki, so I installed MediaWiki on a separate sub-domain. Having multiple accounts is so 1990, therefor integration was wished. That was not as easy as I hoped.
Therefore, my solution was: Single Sign On.
IDP
Step 1, installed SimpleSAMLphp as an IDP on the sub-domain sso.myportal.nu
Created my own Module which looks up users in my database. Logging in to the SimpleSAMLphp admin portal, to test/verify if it works, looks great (screenshot attached).
SP
Step2, installed SimpleSAMLphp as an SP on the sub-domain wiki.myportal.nu
Hooked the SP up to my IDP. Logging in to the SimpleSAMLphp admin portal, to test/verify if it works, looks great. I get authenticated through the IDP in my user database (screenshot attached).
MediaWiki
Then installed two plugins into MediaWiki;
https://www.mediawiki.org/wiki/Extension:PluggableAuth
https://www.mediawiki.org/wiki/Extension:SimpleSAMLphp
That should enable SSO.
When clicking on the Login link in MediaWiki, I get redirected to the logon page of SimpleSAMLphp on sso.myportal.nu – so far so good.
But, contrary to my expectations.. Logging in, does not work. It seems that I get redirected between sso.myportal.nu and wiki.myportal.nu
I've enabled DEBUG mode, the only Warnings I see seem to be this:
Could not load state specified by InResponseTo: NOSTATE Processing response as unsolicited.
I have the config files and log files from both the SimpleSAMLphp installations attached below (a bit too much text to copy/paste here).
config and log files
After a day and a half looking through Google, I’m kind of stuck. Anyone here any ideas?
Well, after two very long nights, the solution has been found.
First of all, if the "Test configured authentication sources" option on the "Authentication"-tab of your SimpleSAMLphp works... That is no guarantee that it will actually work.
In my case, the IDP and SP were on the same server. Different sub-domains. I had every setting in the config.php adjusted, so there were no settings the same for the IDP and SP (cookie names, passwords, etc, etc).
The "Test configured authentication sources" option on the "Authentication"-tab of my SimpleSAMLphp worked! But MediaWiki still did not.
Apparently, this can also be caused by a mismatch of some settings in the config.php compared to php.ini
I found a link to this page in an old Google Forum, where they mentioned the solution. I could not believe it worked, but was desperate, so tried it.
The storage engine should be something else then the default.
In my case I connected SimpleSAMLphp to a MySQL database (can be sqlite, or anything else, as well).
'store.type' => 'sql',
'store.sql.dsn' => 'mysql:host=localhost;dbname=simplesamlStuff',
'store.sql.username' => 'simplesamlUser',
'store.sql.password' => '1234567980',
'store.sql.prefix' => 'sso_',
Both the IDP and the SP can use the same database, as long as the prefix is different. It will create the tables it needs automatically, it just needs to know where to connect to which database with which credentials.
The reason I'm not deleting my question, but answering myself... Is that I hope someone will find this post and find it helpful. Without spending so much time on this like myself.
Related
I had a pretty good homebrew login setup on my site using both a local registry and working with Facebook, Google, and Twitters 3rd party auth tools.
But now that I've secured the site with an SSL cert it seems to have been borked in an odd way. As near as I can tell, the Sessions won't take the first go around, but try again and the session kick in, it was working fine before the SSL switch over, so I feel like I'm missing something related there.
Is there something I should be paying attention to in particular? Some sort of common misstep for someone that has never used PHP sessions in an SSL environment perhaps?
Turns out in this case, watch out for missing "www" at the beginning of redirect URLs.
I've been developing a Symfony app (learning Symfony with the goal of replacing an existing "old school" PHP script with it) and am having an issue with putting it "behind" our Shibboleth authentication.
Why do that? For this app I need $_SERVER['REMOTE_USER']. The app doesn't have local accounts, the user doesn't log into the app, but, like many resources, we protect them with some form of authentication.
I have two sites - virtual hosts running on the same physical server. (CentOS 7). The first site has the following in its .htaccess file:
authtype shibboleth
ShibRequestSetting requireSession 1
require valid-user
I have a "phpinfo.php" file in there, too, and can run that script and, after the Shibboleth authentication step, get the output which includes the correct value of REMOTE_USER.
The other virtual host is set up as a Symfony 3.1 app. I've added those three lines to the top of its ".htaccess" file - but after going through the Shibboleth authentication step, the browser gets into a loop and goes no farther. (In Chrome, the 'favicon' is replaced with a looping arrow, and it never stops turning.)
If I hit and then view the source of this still-empty page, I see the following error message:
Error Message: Error decoding authentication request message
I'm not sure how to start to resolve this issue, and was hoping that someone has seen this and knows how to help.
Thanks.
Best,
Stephen
If I understand well, you are trying to make the Service Provider part in Symfony and you already have an IDP working with Shibboleth.
In my case I had also a similar problem and it was because after the Assertion the apache SP was returning to the root URL. I learnt after reading a lot of documentation that if this is not set correctly you can add an attribute in the shibbolet2.xml configuration called homeURL:
<ApplicationDefaults entityID="https://sso/saml2/idp/metadata.php"
REMOTE_USER="mail"
homeURL="https://symfonyApp/redirect/after/login">
Try it out and restart the shib daemon: /etc/init.d/shibd restart
It may be another as well. But it sounds to me that there is some misconfiguration in your SP side.
I have a drupal 7 site that I just moved to a new server. I'm logged in as admin, but when I click the logout button on the admin bar (I have admin module installed) or on the /user page, I get the following:
Page not found
The requested page "/user/logout" could not be found.
Looking in the apache logs reveals a 404 for /user/logout.
So, what's going on here? Flushing caches both locally and through the admin menu in drupal does nothing--I remain logged in, and the admin bar is still there, so I don't think it's a cache problem.
I'm fairly new to drupal, so please include extra detail in any responses. I won't necessarily know where to put php code if you just give me a block of it without context.
This turned out to be something fairly specific to my case. I had an module installed which used the CAS module. It allowed authentication through a particular ldap server. (This module was built for all users of that particular ldap server, and isn't home-made or available on the drupal site) We'll call it foo_cas for expedience. When I moved to the new server, foo_cas was no longer required--besides that, foo_cas broke and no longer allowed me to login to the ldap server. My new server did not have the php ldap plugin installed, and I suspect that that's why.
Anyway, after the move, I couldn't log in again to disable foo_cas (because of the above ldap problem), so I just deleted the folder sites/all/modules/foo_cas on the backend. This is what broke the logout url. I'm not sure what did it on the code level in foo_cas.
My solution in the end was to put the foo_cas folder back in the sites/all/modules directory, which made the module available again, but disabled. I then used the uninstall tab under modules in the UI to uninstall foo_cas.
I suspect foo_cas made a database change when it was installed that needed to be undone properly by uninstalling it. Now, /user/logout works again.
I'm trying to build a service proviuder (SP) site for a client using a SAML2.0 based user ID system.
I've been able to install simpleSAMLphp on my server and have tested it with an open IdP authentication network - all is working fine if I just create php files which demand authentication against this IdP. Simple adding this to any page makes it work.
require_once('../simplesamlphp/lib/_autoload.php');
$auth = new SimpleSAML_Auth_Simple('default-sp');
$auth->requireAuth();
$attributes = $auth->getAttributes();
Within CMSMS however, if I add the above as a user defined smarty tag (the usual way of including php) I get a "state lost" error. I've tried adding it to the page meta data (via the content interface) as well as simply in the body of the page or at the head of the template.
I always get:
State information lost
State information lost, and no way to restart the request
Does anyone have any ideas what could be going wrong? I've tried the usual fixes for this error messages (adjusting the domain the cookies are assigned to in php.ini etc). No joy.
This seems like conflicting session management between simpleSAMLphp and CMSMS.
A simple way around this is to install memcached, and use the memcache session handler instead of the php session handler in simplesamlphp.
http://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_2_1
similar session conflict is also with eZ publish (4.x) and Symfony2 (2.3+). SQL session storage solves that problem
I have my Wordpress install and MediaWiki sharing the same login information. Unfortunately, users need to log into both separately, but at least they use the same credentials.
What I would like to do is cause a successful login on the Wordpress blog to also cause a login for MediaWiki (ideally both directions). There are two ways this could happen:
Logging in causes a login on the other application (writes the cookie and creates the session in the DB)
Accessing an application checks for the cookie of the other and then automatically logs in.
Since the usernames are shared it seems like the latter should be pretty easy to do. Any tips would be great.
The primary problem you are going to run into is that you'll have two login forms, and two logout methods. What you need to do is pick one of the login forms as the default, and redirect the other one over to it.
I've been able to successfully integrate bbPress + MediaWiki + WordPress + WordPress MU, but I wrote a lot of custom code to do it.
I'm using the bbPress login page as the default (and .htaccess rewrite to /login/), and then I created my own MediaWiki authentication plugin (which looks a lot like the one you are using), except my plugin checks the WordPress/bbPress cookie for the login information and automatically logs the user in.
I created a customized /logout/ link that runs the bbPress logout, and also kills the MediaWiki cookies at the same time.
Then the last step was to redirect all of the other logout / login links for bbpress, mediawiki, etc, over to my consolidated one. I used .htaccess rewrites for this rather than mess with core code.
Still a work in progress, but it works fairly well.
You could consider some kind of single-sign-on software. I am unaware of any that are free and I've only ever used SiteMinder which is neither free nor good. Crowd may be better (but is again not free).
I've seen a setup going through Invision Power Board, using IpbWiki and a Wordpress integration mod. Mind you, it's expensive and excessive.
They both support OpenId now.
MediaWiki's extension
WordPress's plugin
There are probably other options for using OpenId, but I think that is the best solution available.