Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Barebones SSO
#1
Hi,

I have implemented your pretty damn epic SSO server and client into a custom bespoke smarty website backend. I have a what I think is a simple question but for me right now being rather new to your software, hard for me to think up the best and safest way to do the following:

Currently SSO is setup on domain.tld1, diffdomain.tld, diffdomain2.tld. each with their own client and API key using the same namespace.

So... What is the best approach for restricting some users from logging in on some domains?

EG: user1 can only login on domain.tld1 & diffdomain.tld BUT NOT diffdomain2.tld?

Thanks for the input when it comes & I can elaborate more if you need more info
Reply
#2
Hmm...that could get to be a bit tricky.

Tags are possibly the best option here. If the user doesn't have the tag for access to diffdomain2.tld, then they don't get access. Of course, a rule like that will impact all users of diffdomain2.tld. Depending on the situation, you could apply tags to users inside your own 'index_hook.php' file. You could also use tags for the inverse: Allow all users to access diffdomain2.tld *except* those who have a certain tag.

I would need to have some information on how users of diffdomain2.tld get signed in to provide a more detailed solution.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Reply
#3
(01-28-2017, 10:53 AM)thruska Wrote: Hmm...that could get to be a bit tricky.

Tags are possibly the best option here.  If the user doesn't have the tag for access to diffdomain2.tld, then they don't get access.  Of course, a rule like that will impact all users of diffdomain2.tld.  Depending on the situation, you could apply tags to users inside your own 'index_hook.php' file.  You could also use tags for the inverse:  Allow all users to access diffdomain2.tld *except* those who have a certain tag.

I would need to have some information on how users of diffdomain2.tld get signed in to provide a more detailed solution.

Thanks for the reply,
This is how I've set it up right now:

1)User goes to ANY.domain/ADMINAREA that has an include of a file called 'checkuser.php' (contents below)

PHP Code:
    // These two lines should be executed as soon as possible.
    
$sso_removekeys = array("sso_impersonate""sso_remote_id");
    require_once 
"CLIENT-DIR/config.php";
    require_once 
SSO_CLIENT_ROOT_PATH "/index.php";
    require_once 
SSO_CLIENT_ROOT_PATH "/functions.php";

    
// The rest of this code can be executed whenever.
    
$extra = array();
    if (isset(
$_REQUEST["sso_impersonate"]) && is_string($_REQUEST["sso_impersonate"]))  $extra["sso_impersonate"] = $_REQUEST["sso_impersonate"];
    else if (isset(
$_REQUEST["sso_remote_id"]) && is_string($_REQUEST["sso_remote_id"]))
    {
        
$extra["sso_provider"] = "sso_remote";
        
$extra["sso_remote_id"] = $_REQUEST["sso_remote_id"];
    }
    if (!
SSO_LoggedIn())  SSO_Login("""You must login to use this system."$extra);

    
// Fields names from the SSO server API key mapping.
    
$fields = array(
        
"username",
        
"firstname",
        
"userid"
    
);

    
// Reads user information from the browser cookie, session,
    // and/or the SSO server into a more convenient user object.
    
$user SSO_GetMappedUserInfo($fields);

    
// Test permissions for the user.
    //if (!SSO_IsSiteAdmin())  SSO_Login("", "insufficient_permissions");

    // Get the internal token for use with XSRF defenses.
    // Not used in this example.
    
$bb_usertoken SSO_GetSecretToken();

    
// A simple example.
    
if (isset($_REQUEST["action"]) && $_REQUEST["action"] == "logout")
    {
        
SSO_Logout();

        
$url SSO_GetFullRequestURLBase();

        
header("Location: " $url);
        exit();
    }
    else
    {
        
setcookie('ADMIN_COOKIE'$user['userid'], 0'/');
    } 

As you can see I've added request for user field 'userid' which is then set as a cookie for the site you're trying to access. This userid corresponds to a userid in a SINGLE 'masterdb' THAT EVERY SITE USES (ergo, they use same table of users) i have that every site looks at as valid user accounts. 

This cookie is then set and you then login to backend. It is kind of 'logging in twice' as SSO barrier and then the cookie set for the corresponding userid of the admin backend.

This is not the best way of doing it i think but as I am integrating into an existing bespoke system it was the way the old login system worked for 'valid users'

I reckon there are 'better' checks I could do on the SSO level to check? or use the SSO server fully for the whole master? but I do think fields is the way to go?

The cookie check in each backend system currently does the following:
PHP Code:
//--------------------------------
// Checks for a user cookie
// @access public
//--------------------------------

function isLoggedIn() {
 
 
    
if ( !isset($_COOKIE['user_ADMINTABLE'.$this->table]) ) {
        
        return 
0;
        
    } else {
        
        return 
1;
        
    }
 
              
}

//--------------------------------
// Returns user's details
// @access public
//--------------------------------

function getUserDetails() {
 
 
    
if ( isset($_COOKIE['user_'.$this->table]) ) {
        
        
$sql      sprintf("SELECT * FROM %s WHERE id = '%s' LIMIT 1"$this->table$_COOKIE['user_'.$this->table]);
        
$result   $this->_db1->query($sql);
        
$userDets $result->fetch_assoc();
        
        
    }
    
    return 
$userDets;
 
              


So, given this info what are your thoughts?

I can change any/all of it for the best course of action. Thanks for your input and if you need further info let me know.
Reply
#4
Fields can work too if you want a more refined permission set than what tags offers. Then you can store whatever data you want in the field (e.g. a string, possibly JSON).

By the way, you've got a SQL injection security vulnerability in your getUserDetails() function. It assumes that the user ID in the cookie "'user_' . $this->table" string is valid and is then put into the SQL query via sprintf() without sanitizing the input. sprintf() is not a good way to build a SQL query.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Reply
#5
(01-29-2017, 02:09 PM)thruska Wrote: Fields can work too if you want a more refined permission set than what tags offers.  Then you can store whatever data you want in the field (e.g. a string, possibly JSON).

By the way, you've got a SQL injection security vulnerability in your getUserDetails() function.  It assumes that the user ID in the cookie "'user_' . $this->table" string is valid and is then put into the SQL query via sprintf() without sanitizing the input.  sprintf() is not a good way to build a SQL query.

Thanks for rp thruska.

Yeah that userdets thing is very very old code (let's call it grandad code from when I took over this project). I've only just began fiddling intensely with this login stuff on this project. I am changing it all. This is what I have come up with:

(note, registration is of course not open for this closed system)
SSO login users have a single new custom field called 'USER_ID' which is a number. That I have set manually that matches the user to a master MySQL db with the same 'USER_ID' 

(note, master db has three new columns called 'SITE1','SITE2','SITE3' which are switches 1,0)
Once login succeeds I am going to be creating a class(checkuser or something) that then looks for the site switches. if 1 allow, if 0 redirect or throw error page (unsure which i'll do for now)

All backends have your SSO 'check' stuff on them so that would be securing them from unauthorised access in that regard correct?

Then my SITE1 etc flags on our inhouse master user db with correct coding will allow/disallow based on the userid check for column flag?


I do hope this makes sense, does it seem to be the best approach?

Also, is there another component/plugin that would allow me to edit users without searching manually in the SSO server or some code snippet? I don't want to 'hack together' something to edit users and become vulnerable.
Reply
#6
I guess that will work. It's not necessarily how I would have done that. I would have either gone with multiple tags or a SSO server field that had a comma-separated list of allowed domains. But you know the system you are working with.

I'm not sure what you mean by the last question.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Reply
#7
(01-31-2017, 09:16 PM)thruska Wrote: I guess that will work.  It's not necessarily how I would have done that.  I would have either gone with multiple tags or a SSO server field that had a comma-separated list of allowed domains.  But you know the system you are working with.

I'm not sure what you mean by the last question.

Thanks for all of your replies thus far, and a donation will be in the works very soon. My last question was with regards to users stored in generic login. Is their an addon/plugin or whatnot that would allow ssoadmin to see list of all users and edit their dets/flags etc?
Reply
#8
"Find User" in the left nav searches both Generic Login and the SSO server users tables. You can edit users that show up in search results. You can control what fields appear and in what order via Edit Configuration.

Leave the "Search Terms" field empty for the defined behavior: "Runs an AND query for the specified search terms across all non-encrypted fields. Leave blank for the 300 most recent users. Some providers may also run searches."

The Generic Login provider applies to that last sentence.
Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Reply
#9
(02-06-2017, 07:08 PM)thruska Wrote: "Find User" in the left nav searches both Generic Login and the SSO server users tables. You can edit users that show up in search results. You can control what fields appear and in what order via Edit Configuration.

Leave the "Search Terms" field empty for the defined behavior: "Runs an AND query for the specified search terms across all non-encrypted fields. Leave blank for the 300 most recent users. Some providers may also run searches."

The Generic Login provider applies to that last sentence.

Ahhhh I see, i instinctively entered something into the Search box... Didn't try with it blank!! Thank you!!

I'll keep you posted on my implementation extensions. Seems to be working very fine with my setup thus far. a few hiccups with a few things but i worked it out. its all reallly simple (when you know how), documentation must have taken you months to complete (and ongoing) thank you
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)
© CubicleSoft