I use SonataAdminBundle with configured sonata_user in config.yml:
sonata_user:
impersonating:
route: _profile_logged
# more config
I have my admin panel under /admin prefix. I've configured UserAdmin (based on User entity) with impersonating field. I've tried to go to impersonate user by clicked link in my admin panel and I saw application (not admin panel) login page.
I checked developer toolbar and I noticed that request for impersonate user was redirected to login page. It's quite strange, because this request has mostly same parameters like previous one (for user list in admin panel). Especially Request Cookies section is identical.
I noticed one difference in Request Headers: first one request (for user list in admin panel) send cache-control max-age=0 but second one (for impersonate) dosen't.
Obviously, I logged to admin panel on user with full permissions (particularly ROLE_ALLOWED_TO_SWITCH).
So, how can I do impersonate directly from admin panel? What could be wrong in my app?
Can you try using config.yml:
sonata_user:
...
impersonating:
route: sonata_admin_dashboard
And in security.yml:
security:
...
firewalls:
...
admin:
...
switch_user: true
These work for me.
I detected a problem:
4. Multiple firewalls don't share security context form docs: http://symfony.com/doc/current/book/security.html#book-security-common-pitfalls
And found sollution:
Firewall Context from docs: http://symfony.com/doc/current/reference/configuration/security.html#reference-security-firewall-context
So, define firewall context is necessary if you have separate firewall for application and admin panel.
Related
I'm using laravel 7 i was created roll base authentication using laravel UI, when i tried cross check logged with user in chrome browser, in edge browser i was logged with as admin, after i shared cookies by using inspect-application copied admin cookies and replaced chrome user cookies with admin cookies and refreshed page after refreshing page i get admin access with admin credential. how to solve this problem pls help.
The solution is adding 'password.confirm' middleware to your sensitive routes
like admin dashboard ex:
Route::middleware('password.confirm')->group(function () {
Route::get('/dashboard',[AdminDashboardController::class, 'index'])->name('.index');
});
i hope it was useful .
I am using ion auth library in CI application.In application, there are two types of group user admin and staff.It is working fine for login and logout separately but when I logged in staff module it uses same session for admin as well.I mean both user can not logged in at same time in the same browser.
Is there any trick to separate login session for bot user admin and staff?The application should allow to logged in same browser at the same time.
Any help will be great help for me.
If you are using same browser and have not logged out previous user, It will use that session. You can logout the previous user or different browser for new session.
If its your requirement and you want to achieve this, You will have to set different session keys for different users. Ex.
For Admin:
$this->session->set_userdata('admin_id', 'VALUEHERE');
For User:
$this->session->set_userdata('user_id', 'VALUEHERE');
While auth or login you will need to check:
while checking for admin
if($this->session->userdata('admin_id'))
{
//show admin content
}
while checking for user
if($this->session->userdata('user_id'))
{
//show user content
}
I have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.
Our company has been using this Gigya. One of the implementations we did was an SSO for our group sites that registered to Gigya Site settings. However we got some issues regarding with auto login and auto log out from relative sites that in the same group.
For instance, siteA and siteB are in the same SSO group. However when you logout from siteA, when you refresh siteB, nothing happens which we should expect to automatically logout. The work around we did was to detect the current session of gigya in the browser then if the user's active already expired/deleted, we will trigger our code to logout.
We thought this feature for auto login and auto logout should handle by Gigya scripts? By the way we are using Gigya RaaS premium package.
Thanks!
Have you set the "Logout URL" to siteB?
Look in Gigya documentation in the Single Sign-On, User logout section.
Make sure to complete the following steps to enable a successful SSO
logout:
1.Every member site should have a logout URL. This is a page that contains the Gigya script and issues a call to accounts.logout /
socialize.logout accordingly, effectively logging out the active user
when the page is loaded.
2.Send a complete list of logout URLs to your implementation manager. Make sure to have a logout URL for every site.
3.Make sure to implement user log out with a call to accounts.logout / socialize.logout to notify Gigya.
the logout URL is not implemented for SSO group AFAIK.
and gigya cannot delete the session of your sites ( only call an URL). unless you can yourself chain the logout urls via parameters, it is not feasable. What you are doing ( verifying the gigya session status and calling your own logout ) is the way to go.
I've got an internal web app for my company that uses a login with google authentication system. It's working well for the most part, they can authenticate with google, give consent for my app to access basic user details, and then when they are returned to my app, I can indeed get their user details.
The issue is that I thought once they give consent they wouldn't have to do it each time. Is this an incorrect assumption? As it is now, each time they click the "login with google" they must give consent rather than being redirected back to my app.
I'm using PHP (codeigniter) and a pretty good Oauth lib found on github (fork of phil sturgeon's library). Is there some param I should be passing so the user doesn't have to give consent every time, after the first time?
Google login does not require user consent every time. If you're using OAuth2 Login procedure, you should be able to login a second time w/o re-approvals: https://developers.google.com/accounts/docs/OAuth2Login
In some contexts, however, it is possible for auto-approval to become disabled, with the subsequent requirement of user consent on every login.
The first and most common case is if your application explicitly requests Google to prompt for consent everytime. Check if your authorization request (which you may have copied from an example or sample code) includes 'prompt=consent' or the older, non-standard form 'approval_prompt=force'. Removing these parameters (if present), will likely cause auto-approval to start working.
Another situation is if your redirect URL is based on 'localhost' or some other URL that does not belong to the global DNS namespace. In this case, for security reasons, Google sets a cookie on the user's computer, in the accounts.google.com domain, to signal that the user authorized _this_device_ to login to 'foo' on localhost (or local domain); Google will only auto-approve w/o consent a 2nd request if it finds the cookie. The reason is that the meaning of 'localhost' (or local domain, or other URL not built on global DNS namespace) is device-dependent, and allowing the authorization to apply across devices could introduce security risks. So if your company has configured browsers to clear all cookies on exit, and you use a non-absolute URL, you could see your users having to consent everytime. The solution is either to host your endpoint on an Internet-valid hostname (the host doesn't need to be accessible from outside the Intranet, just the hostname needs to be globally valid), or you need to exempt accounts.google.com from the cookie clearing policy.