I'm looking at using Wordpress as a small-scale CMS and would like to use our company's existing authentication system to manage users so that they don't have to remember yet another username or password.

So far, I've got it set up so that users can authenticate to our company's system using WSDL/SOAP. A successful authentication returns a GUID, which I can then capture.

I can get these GUIDs ahead of time and tie them to the user accounts in Wordpress. I was thinking that it would be fairly easy for me to have Wordpress check for an existing GUID session variable, compare it against the user database, and have the person set to be logged in as whichever user account the GUID matches to.

I wanted to get feedback - is this a bad idea? Good idea? Suggestions?

I'm familiar with the basics of Wordpress, but I wasn't sure exactly where to go once I've captured the GUID for comparison. I'm sure that I can figure it out with a enough reading of the codex and some poking around, but I was hoping for someone to point me in the right direction.

Thanks!

8/10/2012 2:01:12 PM

write your own function and populate $current_user

http://codex.wordpress.org/Function_Reference/get_currentuserinfo

[Edited on August 10, 2012 at 2:24 PM. Reason : more importantly, populate the $user_ID global...i think]

8/10/2012 2:21:32 PM

if you're talking AD the objectGuid is nice becaue it wont change even if the user's first/last or login name changes.

i would just make sure you arent exposing it to the browser/user via request parameters/cookie values since its kinda/sorta sensitive data.

im sure you're all happy with your cool soap service (soap is really great and i love it), but as an alternative method of authentication you may want to see if wordpress supports SAML. If it does then you can install active directory federation services 2.0 as a SAML 2.0 Idenitity provider and set it up to provide the assertions you need for wordpress.

if wordpress supports saml then the advantage is that you dont need to alter wordpress code to handle the authentication, downside is you'd need to spend a little bit learning saml and setup the idp (takes about an hour).

also w/ saml you can use multiple IDPs so lets say you want users in another company to be able to access this (or maybe you do something w/ that requirement in the future) they can setup an IDP, you trust it, and then their users get to login with their existing creds in their own system. no external user credentials for you too manage! yippie!

[Edited on August 10, 2012 at 2:55 PM. Reason : f]

8/10/2012 2:53:21 PM

OpenID, man...OpenID

8/12/2012 1:45:36 AM

opensso

8/13/2012 8:14:38 AM

Thanks for the feedback! In the end, it was as simple as getting the GUID (response via SOAP authentication), using that to get the Wordpress ID of the user, and then using a combination of:

get_userdata($wp_user_id)
$wp_user = wp_set_current_user($wp_user_id)
wp_set_auth_cookie($wp_user_id)

in order to get Wordpress to identify the user as logged in.

Quote :

"im sure you're all happy with your cool soap service (soap is really great and i love it), but as an alternative method of authentication you may want to see if wordpress supports SAML. If it does then you can install active directory federation services 2.0 as a SAML 2.0 Idenitity provider and set it up to provide the assertions you need for wordpress. if wordpress supports saml then the advantage is that you dont need to alter wordpress code to handle the authentication, downside is you'd need to spend a little bit learning saml and setup the idp (takes about an hour)."

Wordpress supports SAML, through a plugin at least, but I don't have the option of using anything except the company's existing authentication system. We have multiple sites worldwide and they "force" us to use their central authentication. Thanks for the suggestion, though. I'm not very familiar with SAML, so I think I'll read up on it!

I have another question that people might be able to help me with: this is a Wordpress 3+ installation and in previous versions I've used the "Exec-PHP" plugin to let admins (the only users) write actual code into their pages via the HTML tab. This has been fine - they're all perfectly capable and trusted.

With this new installation, however, there are two types of users - those who should not be allowed to enter any code whatsoever and those who should. The latter are all set as admins. The former all editors. The problem has several components:

1.) How do I allow unfiltered PHP (or HTML) to be entered using the HTML tab,
2.) How do I prevent switching from HTML to Visual tab from destroying the code entered via the HTML tab, and
3.) How do I disable the HTML tab for non-admins altogether?

I have Googled this to exhaustion. There are many plugins that do not work (in the case of #1, they leave most of the code, but break the "<?php" tag) and #2 seems to be a problem with TinyMCE. I've tried CKEditor, but that doesn't fix the problem, either.

Surely I'm not the first person to want to do this! Any suggestions? I'm not familiar enough with Wordpress (or WP3 in particular) to know what functions to disable/enable. It seems as if it should be so simple as to say something like

if(!is_site_admin()) {
    // remove HTML tab
}

if(!is_site_admin()) {
    // do not filter
}

9/4/2012 9:35:34 AM