aad-sso-wordpress icon indicating copy to clipboard operation
aad-sso-wordpress copied to clipboard

Add ability for users that have valid, active AD tokens to be auto-logged in.

Open ghost opened this issue 6 years ago • 10 comments

It would be nice that if a user's AD authentication token was still valid (ie. their login is remembered and they don't need to provide credentials to AD in order to be authenticated again) then they would be automatically logged in by Wordpress.

ghost avatar May 25 '18 15:05 ghost

Do you expect all visitors of the site to be signed in?

psignoret avatar May 25 '18 15:05 psignoret

No, maybe only 3-5%. Why do you ask?

ghost avatar May 25 '18 15:05 ghost

Because if you do (i.e. it's an internal site) then you can automatically have them be signed in. If you don't, it's a bit trickier. Good request, let me see what approach would work for this.

psignoret avatar May 25 '18 15:05 psignoret

Thanks. Maybe a conditional pre-flight to AD might work:

if( has token && token not expired && this is the first page request for this browser session ){
  boolean stillValid = preflight();
  if(isValid){
    redirectLogin();
  }
}

I would have loved to contribute on this but I'm only a Java developer (boo-urns)

ghost avatar May 25 '18 15:05 ghost

+1 for this - just wondering if this is possible?

culmor avatar Nov 30 '18 19:11 culmor

@culmor It's technically possible, although in most cases, simply setting this plugin to automatically redirect to Azure AD will do the job. Does you use case align with that approach?

psignoret avatar Nov 30 '18 19:11 psignoret

In a browser that is already authenticated to azure ad / office 365 the redirect is asking for the credentials again, once I signin the authentication works and even if i open another tab the authentication remains.

The ability to use a pre-authenticated session like office 365 would be good. My use case is staff who are already logged in (sso) that browse to our intranet site (azure) feel that the authentication prompt is unnecessary.

I appreciate your work on the plugin.

culmor avatar Nov 30 '18 20:11 culmor

When this is configured correctly, there are not prompts for additional sign-in if the user is already signed in, like you describe. How have you configured the plugin?

psignoret avatar Dec 01 '18 09:12 psignoret

I believe I have the plugin installed ok - the wordpress site is redirected to azure for authentication and then redirected back on successful login - I have also published the app within the app launcher which also prompts for login. If I have missed something I apologise, I have also removed / re-installed but prompt still exists. I'm happy to email further details if required.

culmor avatar Dec 01 '18 11:12 culmor

Unfortunately the always redirect approach wont work. Most sites (ours included) allow a user to browse anonymously without requiring login.

We've been researching a conceptual approach to this and have found the answer where OAuth flows use a hidden iFrame. Here is the flow:

  1. A user accesses a page on the site for the first time (If a session scope cookie called "sso-checked" already exists do nothing, if it does not then create it and proceed to step 2)
  2. Add a hidden iFrame to the page pointing to authorization server URL (the same URL the user is redirected to when clicking Login). Set the redirect URL to a special page (lets call this /sso-postmessage).
  3. If the user is already logged in then the iFrame request for the authorization server URL will result in a 302 code and redirect to the /wp-login.php page (as usual). If not 302 then the user is not logged in so nothing happens.
  4. Within the /sso-postmessage page, if the user is logged in then send a javascript postmessage to notify any parent frame listening that the user has been logged in.
  5. If the parent frame receives a postmessage then refresh the page. The user has now been autologged in (local auth cookies already set in iframe exchange).

This has the benefit of allowing a user to be autologged in even if they logged into the authority somewhere else.

The iFrame must be placed as high up in the page as possible to reduce the amount of time before postmessage triggered page reload

ghost avatar Feb 19 '19 22:02 ghost