So I am implementing this single sign on feature using Azure AD as the authentication provider. My question is : is it possible to register just one centralized application for potentially multiple deployments?
doc
single sign out
I also want this single sign out feature. i.e. if a user log out of his/her outlook account, my app will react to it and also perform a logout.
The doc specify that I need to set the LogoutUrl field in AAD and do the implementation. The problem is I can only fill out one LogoutUrl for each registered application. I tried move this logout url to the reply urls but the endpoint will not fire.(only work when filled in the logout url field)
Scenario: I have one core app for potentially multiple deployments, and they all have their unique urls.
abc.com
abc1.com
abc2.com
The list will go longer, so it is painful if I need to set up the application for each one. Can I get around by just setting one centralized app?
For the redirect url I think I can set up multiple reply urls. Or can I?
The difficult part is the logouturl: AAD only allow to set up one value, so I need to set up a centralized endpoint (logout.com/logout) to receive the logout call, and then redirect the call to the associated deployment. ( a user log out from abc.com, logout.com/logout is fired, it will then need to identify that the logout happens in abc.com, then it direct the call to abc.com so abc.com can receive and perform cleanups.)
For Azure Active Directory, you can have reply urls spanning multiple domains. So that works. You can also use these reply urls as part of your logout process. The logout url setting is optional, as far as I know.
https://login.microsoftonline.com/{0}/oauth2/logout?post_logout_redirect_uri={1}
(How to signout from an Azure Application?)
Remark: Azure AD B2C only supports reply urls within a single domain.
Edit: It seems I misunderstood your question. Do you want a redirect to abc.com when the user logs out from abc.com? use the redirect url. Do you want to clear the session in abc.com, abc1.com, abc2.com when the user logs out from abc.com? This is more tricky since AAD opens up your logout url in an hidden iframe (=> "Front-channel signout", a GET to the designated URL). If you want this to actually clean up all your domains, you need to get creative... not sure what the best way ist. You could try returning HTML that in itself has iframes to all the domains.. but i don't know if it will be properly evaluated.
Related
Our new site, example.pro, uses Firebase authentication. A small subset of our old example.com users will pay to subscribe to the new site but most will continue to use the old site anonymously.
Firebase Auth makes it easy to remain logged in to example.pro, but these privileged users might visit the old site for various reasons, including by mistake, and from different devices. So for these users I would like to detect whether they are logged in and redirect them as transparently as possible offer them a link to the new site that they can ignore and continue to use the old site, if they wish.
I have considered placing an iframe from example.pro on example.com that would trigger a dialog. Would that be safe?
Do you have a better idea?
[I've edited my question to clarify that the old site does not use any authentication or means of identifying the user, and to clarify that I want users to be able to choose to remain on the old site]
Firebase Authentication does not support multi domain authentication or something like SSO. The best you can do you implement JWT based custom auth that primarily relies on Firebase Auth. I've done that in a couple of ways and the auth flow mentioned below works best for me:
Select a domain for Firebase auth (this will be the domain where users will be logged in via Firebase directly)
When user visits one of your subdomain, let's say app.domain.com for this example, you check if there is any token present in the localStorage of browser (or any local storage of the respective platform). If yes, that means they are logged in. (I'll come back to the token later)
If the user ain't logged in on the subdomain, go to the domain where Firebase Auth works, make a call your server with the Firebase IdToken, verify that and generate a temporary token and return it. Make sure you store it in your database on server side. After that, redirect user back to the subdomain where they were trying to log in with the new token in query param. For example, your URL may look like: https://app.domain.com/login?temp_token=thatTempTokenGeneratedOnServerSide1234.
Make another request containing that temp token to your server from the subdomain and validate it (like check the UID and if it is expired and maybe if the IP of user is same when the token was created).
Generate another JWT (preferably one with long life) (You might want to look at Rolling Token Auth for better security) and return it to the client and store it on client. This JWT ideally would contain only the UID of that user. So whenever the user makes any subsequent requests to the server from that subdomain, add that token in request header (or keep it in cookies as per your convenience) then verify it on server side for processing the data.
If the token is expired, repeat the auth flow.
I've been using this for a while and found no issues. Just make sure you read about the access tokens and refresh tokens about how that works. I'll try to add a flowchart asap meanwhile feel free to ask any questions.
I have a Wordpress website and a Chrome Extension. If the user logs in on the website, I want the Chrome Extension to be aware of that (and vice-versa). The Chrome Extension won't have a login form in it; the user will always log in through the website login form.
When you log in on the website, Wordpress by default sets its authentication cookies to identify the user. What I initially had in mind: I would also like to return some kind of access token, which I would store somewhere where the extension can find it and use it to make authenticated requests to the Wordpress REST API. But.. where do I store it (in a safe manner) so I can find it within the extension?
Perhaps I should try a different approach?
Thank you!
What you could do, the simpler way:
create an Ajax action or a REST API route
as you can read in the documentation, the authentication is cookie-based. So once the user is logged in from the WordPress login form, the authentication cookie is added to your browsing session
without overrides, the cookie will also be forwarded when using JS HTTP queries (eg ajax)
your route could check something like is_user_logged_in() or wp_get_current_user() like available methods. And return the result (among other things if needed) to your plugin JS
you may need to change the WordPress cookie configuration, so they can be accessed from anywhere (any domain), check this.
Better way:
would be to use a plugin like this to implement REST API Oauth2 authentication
user should be able to login directly from the extension window (need development), and then use a refresh token feature to keep the user logged in.
I believe you may also need to update your actual login form, if its classic or OAuth rest API login, should be able to send back the required OAuth token (access and refresh tokens), to the frontend (then stored in local storage or else) to be used by the extension. To prevent having to log in twice.
I have a Chrome extension that communicates with my Meteor app through a REST API created with the Restivus package.
The user authenticates to the REST API and then uses authenticated tokens to make any further requests.
So far, everything works fine, as long as he stays within the extension. However, from the chrome extension, I'd like to redirect the user to his profile page on my main website. When that happens, he's no longer authenticated, and must re-sign-in to access the profile page.
I figure this is because the REST API session and the webpage session are two completely different sessions on the server (even though both the API and the webpage run from the same server). My question is, is there a way to maintain the user's logged-in state as he moves from the extension to the main website?
I figure there are a few options:
I'm using the standard meteor accounts package. Is there a way to push whatever standard cookie / data that the accounts package uses, to the user's browser, so that when he goes to the website, he'll be considered logged in?
Push a custom cookie to the user, which I then check for and log him in when he first comes to the website. However, I don't know how to push a cookie through a REST API or generate one in the Chrome extension
Use DDP to communicate with the second session and transfer the login credentials.
I don't know if these are the best options (or even how to implement them if they are...). Has anyone figured out a way to do this already? Thanks!
I would suggest you to develop your own flow of authentification using a token as an URL parameter. You should achieve a similar experience that slack provides with magic authentification links
The idea is to generate a token and add it to the Meteor.users collection for the user logged in your chrome extension.
Then, redirect your user to an url with the token as a parameter. The app checks which user is linked with this token and log him in.
You can get inspiration on what is done in the account package to handle enrollment and reset links, or in the passwordless package
I have an existing Wordpress site. The plan is to rebuild the site using the cakePHP framework. Due to time restrictions, I want to replace individual sections of the Wordpress site one at a time. This will mean that both apps will be running side by side for a certain period of time. I need to control access to the cakePHP app using the authorization provided by Wordpress. I'm not sure the best way to go about doing this. I've seen similar questions asked a lot, but I have not yet found a clear solution.
I'm thinking about two approaches:
Plan A:
Configure Cake to look for Wordpress's authorization cookies.
configure Cake to look at Wordpress's database.
Borrow some of Wordpress's authorization logic to teach Cake's Auth component how to authenticate WP users.
Plan B:
set up an authorization API on my Wordpress site.
set up separate auth component in cake.
ping the WP endpoint when a user hits a protected page in the cake app and then manually log in the user. (This would create a second set of auth cookies)
Do either of these sound like the right approach? Is there a better way to do this?
Helpful references: Article about Cake session handling, Cake Auth component documentation, Cake Auth tutorial, brief overview of WP authorization, a more in depth look at wordpress authorization
UPDATE
We've started working on this, and it seems like it will work, but there is a very tricky aspect involving password hashing that warrants its own question. If you're following this thread, you may want to have a look.
I once had a similar situation: Cross framework authentication zend + codeigniter which was few months ago...
Anyways, this is what I will prefer:
set up an authorization API on my Wordpress site.
set up separate auth component in cake.
ping the WP endpoint when a user hits a protected page in the cake app and then manually log in the user. (This would create a second set of auth cookies)
Here, I would suggest a slight change which is do-able.
Make sure, you have a token system of SSO. As in, when person is logged in on Wordpress, set another cookie which will have a token: Token will be username + password (hashed) + secret key, which will be same between Wordpress and CakePHP. On either site, look up for cookie and manually log the user in or just perform a database look up. Hashing is important for that cookie!
However, if the site is using different domains, you might need to re-strategize:
I had different domains once. At the login or unauthorized page, I would ping the other website and bring up their login box. On the other website if the user is logged in, they get post login page and if request URI has sent a token, we perform normal operation and return the authorized token to this (current) domain.
In simple words:
Site A = WordPress & Site B = CakePHP
Site B hits a page where authorization is required then, ping Site A for a login (as it happens when u do Login-with-Facebook sort), which will request via a Token (private key) and REQUEST_URI which will be part of SSO verification table on Site A, if person is already logged in then, Site A will return (via POST) a token, which further will be decrypted via (private key) of Site B and log the user in. Private key of B and A will be same.
Hope this was understandable.
Questions? :)
Answer to your questions in comment:
Ideally, why we use SSO? We use it because of many constraints. For example: You have a database of say... a million row with more than thousand tables, you need to add a module over ur huge app already... so, instead, you will use another database... SSO will return user information, which can further be replicated. For example, when you click on 'Login with Facebook', it returns requested information, like email address, or user's name or even profile picture. Which can further be added to our database... Keeping different databases is strongly recommended :)
To your 2nd and 3rd question: Should both sites reference the same users table in the database? different databases is recommended unless, you are using the same data. Or say changing the software platform.
Should I copy the site-specific user rows into separate user tables for each app? Yes, that should happen automatically. Once you are registered on a main site, nothing happens, things should happen once you are logged in already and then go to site B... Once logged in, user info can always be requested :) That way, new site will have active users ! 2 birds?
Don't complicate (bother) yourself with how what works but, concentrate on how, what is achievable in short period. SSO - Logged in - Restricted page - Look out for log ins - Either login - If already logged in - fetch user info - If user info exists - login via secondary site OR set the new user info . Done!
We developers love flow charts! Don't we? I just created one:
Further answers:
Does the "Fetch User Info" stage mean that we take the user info from the site which is logged in, and create a new user (row) automatically in the other site?
Ideally, you will ask permission from the user before they 'allow' their info to be used but, it varies how your privacy policies are.
In other words, one site handles all the registration/user-creation and the other site just waits for that user to show up and trigger automatic creation. OR at the moment a user registers on the one site, BOTH databases get a user row inserted?
one site handles all the registration/user-creation and the other site just waits for that user to show up and trigger automatic creation. You can have both. Sign up on your website and also a trigger based automatic creation. Depends on your strategy. OR at the moment a user registers on the one site, BOTH databases get a user row inserted? That would be a horrible practice! It will kill the motive of SSO. Motive of SSO is to create an auth family which can be used by users so that they do not have to register every now and then for different websites. update only one database at a time and other when required :)
Questions? :)
I have done this once. I don't have the snippets and/or any references to anything. But thought it might be helpful.
Configure WP and CakePHP both to use same session, you can do this by session id and session name,
When User registers for your website, register them using both WP and CakePHP,
Choose one framework that will handle login view from the front end. I had chosen CakePHP as I was more proficient with it, once the login is successful locate the same user in other framework's DB and authenticate the user using their authentication system.
Hope this helps !!!
Suggestions:
If you are building a closed system, meaning you have to be signed in to access anything useful in the site, then you can use CAS . I know it's used by mainly universities, but for closed systems it works.
( If you need to handle anonymous users the suggestions below might help)
Keep it simple and, similar to Part A of your plan, have a cookie ( visible by both cake and wordpress ) that simply states if a user is logged in. The cookie should be created/checked by both cake and WP. Cake does not need to look at WP's DB. The cookie can have information on how the users in each system are mapped.
Have a central login screen, this is similar to what CAS does. But please build your own. CAS does not handle anonymous users. I am currently creating a central login screen for work. It's simple. The central login screen will handle all authentication and create the cookie visible to both WP and cake. This would mean that the login link for WP and cake will redirect a user to a common page. The link will need to provide a callback URL so that after the user authenticates successfully, he is redirected back to the original service. You will need to decide on a central DB for user authentication.
The cookie approach has following bonus:
It's a lightweight solution and can be wrapped with an on/off switch. In WP, simply wrap the cookie logic with a wp_options value.
You can use WP's and cake's authentication system. no need to work with API's and/or sessions. No need to couple applications by looking at each other's DB.
You can keep roles and permissions native, meaning WP will work with it's own roles and permissions system and your cake application will work with it's system.
Adding a new "service" to your platform is as simple as "create/check for a cookie" then use the system out-of-the-box auth system to log the user in.
Single Sign On is as simple as creating a cookie. Single Sign Off would be deleting the cookie.
I can definitely go into more detail on each suggestion if you're interested.
Here is the scenario...
I have a site:
http://internet.com
and I set a token(cookie, something like that) from http://internet.com when a user has SUCCESSFULLY logged in.
I also have http://web.internet.com.
On http://web.internet.com I want to display data to users that have that token/cookie/etc available to them.
Here is the use-case
user logs into http://internet.com (asp.net framework hosted on different server - this is our primary product that requires a subscription / username & login )
user then has access to a section that is hidden from plublic view on http://web.internet.com (wordpress site hosted on goDadday - this site contains a knowledge base that we do not want to make public unless they have done [XXXXX] )
both sites are hosted independently of each other and do not share a common username and password
======
Another scenario is to set up wordpress to allow a specific section as a jsonp response. but only if the user is logged in at http://internet.com to allow the user to have access to the jsonp response located at http://web.internet.com
Any ideas from you beautiful people?
It really depends on the level of security you require. You can log a user in to a Wordpress site without a password by using wp_set_auth_cookie, however if you are just validating that a user is logged into the ASP.NET site and then using JSONP to load a page that set's the auth cookie, it will work, however you definitely have some security gaps.
A better solution would be to set a domain level cookie for .internet.com with a token that can be read by any server in your domain. The Wordpress site could then check is_user_logged_in(), and if not take that cookie value and make a back end call to the ASP.NET site to verify its authenticity, and then call wp_set_auth_cookie(). A simple web service would likely be the best option. You would still need some level of mapping between usernames on the ASP.NET and Wordpress site however to know which user_ID to pass.