We have 2 websites A & B and users as AA & BB. User AA should only be able to import application, Start, Stop & Restart website A. Same goes with user BB for website B.
Also when user AA logs in then other website B should have this symbol:
[1]: https://i.stack.imgur.com/HIv7q.png
Have tried following things:
Added users to IIS Manager Permissions.
Added users to IIS Manager Users too.
Changed Identity to specific user at App pool level.
But it's not working as intended.
How do we achieve this?
Related
I am trying to get details of a AD user that logged in a directory pc. I mean that when a user logged in a pc (in AD) by his account and then open a site that's working on intranet, i'll automatically detect his account name, sAMAccountName etc.
Is that possible or i've gotta use an agent or something installed before?
I'm confused about it. I don't want to make a log-in screen for it if possible ofc.
Thanks in advice!
Java 8 + Spring MVC 4
I am learning to the programme and came across one scenario.
There are different roles
1) Admin
i) ABC Admin
ii) XYZ Admin
2) Normal
ABC Admin logged into the system and created a contract, with contract_id: 123
Edit URL is : localhost:8080/myApp/contract/edit/123
XYZ Admin logged into the system and copy pasted above edit URL in the browser.
(Ideally, XYZ Admin should not be able to edit the ABC admin contracts and vice versa)
I need some suggestions/ideas what should I use for this.
I did a search on google and got spring security will be the fit case for this.
You can use
#PreAuthorize("hasAnyRole('ROLE_ADMIN','ROLE_USER')") for access multiple role on a single method
or
#PreAuthorize("hasRole('ROLE_ADMIN')") for only one role on method level in Controller/DAO classes.
We have a website displaying some strange behaviour. It was just updated from ASP.NET v2 running on IIS6 to .Net v4 running on IIS7.5.
It is only used within the intranet and uses Windows Authentication, but the user sessions do not appear to be maintained as I would expect.
The situation is this:
Person A logs in - all good.
Person B logs in - all good.
Person A refreshes their page, and they are now logged in as Person B.
Person C logs in, and now Person A & B are both logged in as Person C.
We are getting the current logged in user by way of
System.Security.Principal.IIdentity winId = HttpContext.Current.User.Identity;
I'm kind of baffled as to what's going wrong here. Does anyone have any ideas?
I have a site , and I want to prevent my users to log in to site for more that one sessions.For example , if a user logged into my site in computer A , I prevent to try to log in to site in computer B (since it is logged in to site in a computer and did not log out)
Is there any solution ?
I have 3 ideas(actually they are bad idea and i am looking for better idea)
1 - use Session State
2 - use Application State
3 - use who2 table in sql server
UPDATE : I have my user management approach , and i did not use ASP Membership
The idea is that you have to keep track somewhere on your server (application state, database, ...) a list of authenticated users. When a user signs-in you will first look if he is present in this list. If he is refuse the sign in. If he is not add him to this list and allow him to login. Everytime the user performs some action on your site update the this list with the date when he performed this action. When signing in if the user is present in the list and the date when he lastly performed an action on your site is older than a treshold date you have defined you could allow sign in.
I have users with accounts on Site A. Site A has been around a long time, and it's expensive (but not impossible) to change its code.
Site B (I'm working on it now!) hosts a brand new web app for the customers of Site A. The Site B app has a list of the usernames from Site A, and maintains preferences and other information about each of those users that pertains to their usage of Site B. Site A and B are different platforms. I think Site A is coldfusion, and Site B is ASP.NET MVC.
I want users to be able to click a link in Site A that logs them into the app on Site B. I was thinking it might work like this:
0) If user tries to go straight to Site B, they just get redirected to Site A to be authenticated.
1) User logs into Site A.
2) Once logged into Site A, they can click a link that takes them to Site B. I was thinking I would do an HTTP Post from Site A to Site B with the username, so Site B knows who is logging in and how to render their pages based on their preferences.
Of course, I don't want any Joe Schmoe to be able to do an HTTP POST to Site B with a username and get to be logged in as that user.
So I was wondering if, using certificates or something, I could make it so Site B is able to know for certain that the POST really came from Site A. Do I need / Can I use certificates for this? Maybe Site A can somehow "sign" its post so Site B can know for sure the post came from Site A?
Or could just a password be enough, where Site A posts a password over SSL along with the username that only Site B knows?
I'm also open to the idea of Site A posting the username and a GUID to Site B, which Site B would then "ask" Site A via a web service if this is indeed a recent and valid GUID that did in fact originate at Site A, but that seems like a trip I can eliminate.
I hope that is descriptive enough. Please feel free to have me explain more. Thank you for your help. :)
Another option would be..
User signs into site A.
Site A creates a guid that is associated with this user but will expire in 5 seconds or some short time frame.
The user is redirected to siteB?UserID=SomId&ConfirmationId=Some Guid
Site B calls a web service on Site A, passing the UserID and Guid and checks to see if this is a valid redirect. (The web service just returns a true or a false).
This solves your issue of trust, as site B is explicitly querying site A, so site B KNOWS that it is using Site A for authentication, and not just blindly trusting that the confirmation is coming from a redirect from site A.
Also, a Guid is unique enough that it's unlikely to be guessed by hackers, and finally, the expiration makes it so that if a hacker DOES guess the guid, it will likely have expired by the time it's been guessed.
Of course, you'll want this all done over SSL.