We are trying to create some .Net applications that will run in the same domain.
eg: www.myintrasite.net/myapplication
We need to create a SSO system, we read some articles but what we see is cookie driven solutions.
The problem is that we need to share the session only in Login context.
If we manage the cookies to share the same session, all applications will share the same session keys, but we need to share only one session key, like "id_person".
A simple example is two applications that have a session key named "order_id", with a shared session, the application A will override the session key of application B, that can cause some weird behavious.
There is any solution for a "session context" or something else?
Thanks in advance.
The best solution is going to be found here. It shows you how to set it up properly.
The way I have done it, is set up a "Central Login" that handles all logging in. Then I have multiple applications that are shown once the user is authenticated. I have App 1, App 2 and then App 3. If a user only has access to App 2 then he only sees that app. You will need to place what is mentioned in the link in all of your applications. On my login button click, I placed
FormsAuthentication.SetAuthCookie(User.Identity.Name.ToString(),
false);
This will set the authorization cookie that be used to verify that the user is logged in and can view your other apps. Here is another link will help you as well.
Mine was a bit more complicated than this since I was using Active Directory and Forms Authentication. Hope this helps you get started.
Related
I've got some external users in another system that may/may not be using OWIN. (I've actually got this problem in a couple projects) I'm trying to solve this with IdentityServer4 and it's Authorize Endpoint but want to make sure I'm on the right path.
Our goal is to have users click a link in the external app and be redirected to IdentityServer4. I would like IdentityServer4 to authorize users coming in from this endpoint, add a particular role or claim, and allow them into the clients without presenting a login screen. Is this possible? I'm having trouble finding examples.
Identity Server 4 Authorization Code Flow example
This is the closest I could find, but we're looking for a framework agnostic solution that doesn't involve modifying the external apps, as I don't have access to their source code in all instances.
I'm looking for a flow like this: User goes to https://someexternalapp.com, clicks a published link like https://identityserver.myapp.com/authorize?requestSecret=asdf1234&username=bob and is redirected to https://identityserver.myapp.com/external?token=dasdfasdf where the claims are issued, and finally redirected to https://someclient.myapp.com with authorization.
Am I on the right track? I'd hate to waste much more time on this and end up at a dead end, could anybody point me in the right direction?
Have a look at Sign-in with External Identity Providers
This will allow you to create a cookie in the https://someexternalapp.com/ app which is then used by identity server to do the authentication without user interaction.
I am working on Asp.Net MVC 5 Razor application. I am using my own database for authentication and keeping data. Now I have a requirement that user with same credentials cannot log in to different devices.
I mean user cannot be logged in from mobile and computer same time. He has to log-out at least from one device before logging in to other device.
I have done research, but in vain because most of them are for Web Forms application and are using membership table.
Any help?
He has to logout atleast from one device before logging in to other device.
Don't do that. When someone clears their browser cache, they lose all relation to their session, so they're not logged in anymore and thus cannot log out. When their IP changes (if you bind a session to an IP), they can't log out either.
Just do this: upon logging in, invalidate all previous sessions for that user.
How to implement this depends entirely on how your custom authentication works, so I can't comment on that.
I am creating a project which has a login portal with multiple applications and websites. I want to allow the user to login and then click any application and have access to it. Some considerations are: each application is defined in a user profile, ie which users can see what. also each application privileges are different for each user. so user a may be an administrator of application a but just a normal users in application b.
What i know.
I can have one auth cookie created in the main portal which with setting the machine key and same authcookie name, each application can use it. I have done a test with this and it seems to work.
My problem
As each site/ virtual directory has different privileges per user and per application when the user access a site i need to get his privileges from the databases but I cant then overwrite the auth cookie userdata with the new details because he may have multiple tabs etc open at a time on different sites. So how can i have an extra cookie store per user and per application for holding application specific details. I know I could go to the database each time but that's allot of overhead for each post back.
Maybe another option is to use the main authcooke for checking the user is logged in then have a new auth cookie per aplication and user, but how can i have 2 authcookies, that may get confusing and the second needs to timeout when the main one does et c i think
Any help suggestions would be gratefully appreciated
THanks
------------------- EDIT -----------------------------
we have one user table for all all sites not 1 per each site. then we map the user to an application and then the user application and role. so when you get to an application it has to check if the user has access and what there role is. all other user details are already in the auth cookie when loggedinto the main site. We do it this way because we have to manage users in one application not each application. Hope this helps understand my requirements.
What you are describing is a 'classic' SSO (single sign-on) example. There are lots of ways people have tried this and they are well documented on Google.
One way to do this is to have your SSO server (e.g. the first place you land and log in) to issue a security 'token' (e.g. a Guid) and then either store this in a cookie or append to URLs. Each subsequent call to an application can look-up the token in a database, verify it's validity and carry on (or boot the user out if invalid).
Using a database also allows you to set a timeout for all applications for which the token is valid.
This can then be extended to allow the database to store which apps each user can access etc. I've described this in very broad terms but it may be a good starting point.
Hope this helps
BTW: querying the database on each request isn't too much of an overhead. I have applications that do just that and are still performant when loaded with 300+ users.
I have the oddest situation...
On my ASP.NET website when the application pool recycles the user is logged out. This is fine. I know this is suppose to happen. But when the user logs back in and selects any link within the website, they are logged back out immediately. They consistently get logged out. I don't know what causes this and I don't know how to fix it.
The odd part is the work-around. If I log in from a different computer or from the IIS Server itself than the user that is getting logged out can log back in.
Does anyone have any ideas as to what is happening?
Standard Forms Authentication in ASP.NET is cookie-based and should not be affected by the session vanishing. But, you're probably relying on something in the session to determine whether or not the user is logged in. If you're using in-process session storage (and it sounds like you are), then your application code might act strangely if you get in a state where the Forms Authentication cookie still exists and is valid but the session information is missing. Instead of going to a different computer, try blowing away your cookies and logging in again, and I would presume that your issue is resolved.
One step is to move to out-of-process session storage (such as the ASP.NET State Server, which is simple to use with a few config changes) or to eliminate session usage entirely (by depending on values stored in cookies, though there are security implications there to consider if these values are not encrypted). Then, take a close look at how your application code handles the condition where a login cookie is set but the session data is invalid.
It's a shot in the dark based on the information provided, but hopefully it puts you or someone else on the right track.
I discovered the problem. In the Security settings of the ASP.NET Configuration each user that logs in needed to have one of the roles defined in the "Description" field. This is very odd to me be but it seemed to do the trick. Anyone know why this needs to be done?
I'm writing an internal web application right now (with ASP.Net Web Forms), and it presents an odd problem. I have to be able to impersonate the currently logged in windows user, and execute a command based on their Windows Authentication to log in.. AND ... if they don't have Windows Authentication set up in the application I have to use to log them in, I have to be able to accept a user name and password. I also have to write the application in .Net 4.0, and secure it as much as possible. I got this to work by NOT utilizing Windows Authentication or Forms Authentication in the web.config, and instead setting session variables to guard against user accessing pages in the web app other that the log in. I did this by creating an oddly name session variable with a value based on their user name (windows auth or not), and then a secret session variable. The secret variable is in the web.config as a 256bit encrypted string, in which I decrypt, and set as the session secret. In order for the page to load, the first session variable can't be blank, and the second variable has to equal the decrypted key value... if the variables don't pass inspection, it redirects them to the login page. I set this up on every page, generic handler, and webservice method in the web app. I make the session timeout after a few minutes of no activity, and on log out, I set all session variables to nothing, and expire all cookies. (I also disable all cache).
My question is... Does this offer comparable security to that of Forms authentication? I have always used Forms authentication, but can't use it here. If I did, the users would have to reconfigure settings in IIS and in he web.config to toggle login procedures (From my knowledge, you can't use both Forms authentication, and windows authentication to manage the security of your pages and other web resources). With the method described above, I can accomplish the best of both worlds, but am curious about the security of my methods. Is there anything else I can implement here to assure the utmost security other that using forms authentication? Is it possible to accomplish the same level of security of Forms authentication without using it?
Thank you for any insight in advance!
Does this offer comparable security to that of Forms authentication?
No
The first rule when it comes to security is don't reinvent the wheel unless you absolutely have to. Any home baked solution you come up with has the potential to be as secure as a provided one like Windows or Forms Authentication. The problem is that home-grown solutions rarely reach that potential. They may test okay, but subtle bugs can remain. You don't want to find out a year later that you were hacked six months ago. Existing solutions have already been tested and used in millions of applications, whereas yours will be used in one application and tested by a handful of people at most.
A quick search suggests that it is possible to implement both Windows and Forms Authentication in the same application, so I'd pursue it further.
Mixing Forms and Windows Security in ASP.NET