how can I synchronize sessionID over multiple second-domain servers? For example, I've got servers(you can log-in into server swarm at any of these), www.service1.com, www.service2.com, www.service3.com, and if you log in at one of them, the login information (+anything else) should persist along them. How can I provide SessionID to other domains? (session itself is stored on sql server shared across the services).
Cross domain logins are possible, but very tricky, and prone to issues.
Generally a scheme to do this will involve a third server that acts a centralized auth server. Login requests on individual sites will route through the auth server and the auth server will pass back a secure token to use as a session id.
I've seen this session id passed back to the server via url redirects, and also through back end server communication.
My personal advice would be to use the auth server as a webservice of some sort, and maintain individual sites logins separately. The workflow would be roughly:
Sign in on a given site
The site would send a behind the scenes request to the auth server asking for authentication and information
The auth server would respond appropriately
The site would login on success, and show error message on failure.
It is possible to use some fancy redirects and some forms of trust to implement a auto login system, but honestly such things are rarely if ever worth it. The above suggestion would end up with them having to login on each individual site, but they'd share the same credentials and profile on every site.
Don't you mean across domains?
This is not possible due to security features in browsers. Browsers do not allow cookies to be accessed across domains.
Related
I Will try to describe this as detailed as possible.
For using the SPA, you need to be logged-in, every request is authenticated by JWT. Login is a simple form with Username and Password fields, which are sent to the server. On the server, there are two types of login (kinda) - AD and Password (determinated by the user type):
API check if username exists and determine its Type
a) if type is Password: Check if password matches the data in Database
b) if type is AD: verify password on the LDAP server
successful login returns generated JWT, which is used for all further requests.
This App is available all over the internet, not just inside the same network as the server.
I would like to have some kind of "automatic login" with Windows account (so you dont need to manually type the username/pass, but the SPA tries to login automatically when u open the Login page).
I tried many guides for something like this, but nothing seems to work properly.
I heard that Kerberos/Auth0 should do the work, but I dont know how to implement it. Also I would still need to get that JWT for further requests. Do I need some kind of Microsoft request? Azure? Anything else? (If is needed, I can create another IIS application just with Login controller).
I hope you understand what I mean, and will be able to help!
Most Modern Browsers speak SPNEGO
Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO), often pronounced "spenay-go", is a GSSAPI "pseudo mechanism" used by client-server software to negotiate the choice of security technology.
It just so happens that one of those client-server security technologies it can speak is Kerberos. (Windows machines generally have kerberos availble by default.).
So to actually get .NET to use kerberos authentication you really need to enable delegation for IIS as that's what speaks to the browser.
I am trying to build a web project that will include user sign in. It will have an asp.net front-end, and an asp.net back-end. I am trying to figure out how this should work with user context and where user sign-in should happen. I believe controlling user sign in is a back-end responsibility, but it seems that many 3rd party validation methods would prefer it to be front-end. As I understand it seems that if I was using something like google or Microsoft validation. It would try to bring up a window, but that window wouldn't be seen by my user, because it was coming from the back-end that is not serving them, and is instead serving the front-end server.
Based on your comments I'll try to summarize a bit here. Do note, that this is not a coding question and should really have been asked on https://security.stackexchange.com/, but I'll give it a go.
A few keywords you should read up on:
Authentication: This is the process of verifying the identity of an entity (a person, device etc.)
Authorization: This is the process of granting access to a given resource based on some parameters - usually based on a verified identity
Identity provider: A system that manages and can verify the identity of an entity (in your example that would be Google or Microsoft)
Service provider: A system providing a service to authenticated entities (in this case your server application)
OAuth, which you use as an example, is not an authentication protocol but an authorization protocol, which makes it important for you to understand the difference. However, OpenID Connect is a protocol/layer built on top of OAuth 2.0 and...
It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server [read: "Identity provider" under the hood]. [source]
Copied from Wikipedia (point 8 removed to avoid confusion):
The communication flow in both processes is similar:
(Not pictured) The user requests a resource or site login from the application.
The site sees that the user is not authenticated. It formulates a request for the identity provider, encodes it, and sends it to the user as part of a redirect URL.
The user's browser requests the redirect URL for the identity provider, including the application's request
If necessary, the identity provider authenticates the user (perhaps by asking them for their username and password)
Once the identity provider is satisfied that the user is sufficiently authenticated, it processes the application's request, formulates a response, and sends that back to the user along with a redirect URL back to the application.
The user's browser requests the redirect URL that goes back to the application, including the identity provider's response
The application decodes the identity provider's response, and carries on accordingly.
This is the flow you're asking about. The only thing the client (front end) does is follow the URLs it's provided from your application in order to visit an authentication server. This server then provides the proven identity that your client then passes on to your server again.
So bottom line is, the client/front end does not perform the authentication, that's handled by the identity provider (a 3rd party backend).
I have software that is serving up hundreds of different websites on different URLs via HTTP. However, we are now adding functionality so that users can login and do various other tasks, however this needs to be run via HTTPS, so we've run into a little problem where the user needs to be known on both websites, but we obviously can't set cookies across domains and can only see user credentials via the HTTPS domain. I'm trying to discover the best way to forward credentials onto the HTTPS site for login, but also let the primary domain that the user has logged in.
I develop an web application by web api2.
My client application is a windows application that developed by C# , .net 4.0.
The client application sends some Json data to the web api application and the application stores data in database.
Now the issue is sending the request with another method except my application and sending dump data to the server.I have authentication on the server but it isn't enough,I need some tokens for handling this issue.
After some searches i find this article and read it, but the client is a web application.
Could i use this method in my windows client app?how?
Bottom line: You shouldn't need to.
By definition, CSRF attacks can only affect client applications that share cookies across domains. e.g. if you visit www.bank.com with your browser and then open another tab to www.evil.com, if www.bank.com does not protect against CSRF then www.evil.com may be able to POST a form submission to www.bank.com while you are logged in and then transfer money by forging the request to the form's action URL on the transfer money page.
If your client is a Windows application, the HTTP client should not have cookies stored for any other service other than your web API.
Note that the above only applies to when cookies are used as the session management mechanism (i.e. not Kerberos, NTLM, Basic Auth, etc).
.I have authentication on the server but it isn't enough
This should be enough as an attacker cannot forge a HTTP request to your API that will be sent along with the victim's cookies as the cookies are separated due to there being different instances of web clients. Much like being logged into Google on Chrome, but then accessing Google on Firefox - you will not share the same logged in session.
Of course, protect your API with HTTPS so the information is encrypted whilst in transit. Note that this does not protect against decompilation of your source code, which is something that is not easy to prevent. At the end of the day you cannot trust clients that are not under your control. You can make it difficult, but not impossible to prevent someone working out or changing what is being sent to your API.
Cross site anti-forgery tokens are a form of authentication. It authenticates the client who's sending the request: the client has to visit a certain page to get the token from the server, so it cannot be any client who has not visited that page and some how just send random data to that server.
The purpose of authentication is for the server to authenticate the client (other way around is also possible, but let's forget that for the moment). You setup the system such that it is very difficult for others to pretend to be your Windows Form app. Note it can be very difficult, but theoretically it's always possible to fake. So the aim is to setup an auth such that an attacker considers it impractical to launch an attack.
This auth should not be mixed up with the authentication to verify the human user. They are different. An app can provide a UI for human users to login, but the app is not written by you. So you need to authenticate 2 things:
the request actually comes from your app, if that succeeds, then
the human user is who he claims he is, otherwise
reject the request
I have an application which uses 2 web sites (so I guess that is 2 applications...). The user logs on via a https website and is then diverted to a unsecure http website application on successful logon (using forms authentication). I (and others) have started getting the message
"The current web page is trying to open a site in your Trusted sites list. Do you want to allow this?"
when the user is redirected.
Is there a way to stop this in the server configuration or in the code ?
Thanks
If the user is accountable for any actions performed on the "unsecured site", it should not be unsecured. It's not safe to authenticate a user on HTTPS, then let them perform actions using that authentication over HTTP.
If someone is not worried about a man-in-the-middle, it doesn't make sense for them to use HTTPS at all. On the other hand, if a man-in-the-middle attack is a possibility (and in general I assume it is) then sending the session identifier cookie (or other credential) obtained via secure login over an insecure channel allows an attacker to steal it and forge requests to the service.
I think what you are doing at login is to post the login information from the secured page to the non-secured page, which in turn pops up that message.
What you could have done is for the secured login to post to a secured page, then redirect from there to the non-secured page. That should remove the message.
That message appears to be IE's trusted sites warning. There is no way to control it from a remote server, nor should there be as it would be a security risk.