Is it possible for more than one site to share a cookie or create a "global" cookie for multiple sites to access? They share the same domain but have different subdomains.
We have several systems and need a way to share authentication between them. When a user is logged into one, we want them to also be logged in to the others.
One site is authenticated through Magenot as it is our e-commerce site. one is through Wordpress as it is our content and the other is an ASP.Net site. They all authenticate to an Oracle back end through a web service but how would I be able to tell if a user is logged into one of the others and if they are, log them into the one they are accessing?
Anyone know how to do that handily?
A cookie can be set for a domain or subdomain, so yes, you can have a global cookie by setting it to your top level domain. In this case you would need to configure each system to use the top level domain for their authentication cookie and the same cookie name.
However, The different systems are going to use different content and encryption for their cookies so I don't think they can share a cookie in the way you intend.
Related
I have 3 separate net core web apps on the same IIS web server. All of them are equals at 90% but every one has its own database, its own users and its own subdomain.
I would like to have a unique web app to login into the corresponding final web app depending on the user logged, basicly because I need all the users to access from a specific URL login.my-platform.com By now every user access through its web app with a login page on its subdomain.
USER FINAL WEB APP
==================================
111 platfA.my-platform.com
222 platfA.my-platform.com
333 platfB.my-platform.com
444 platfB.my-platform.com
555 platfC.my-platform.com
Moreover, from a final web app, a user could create more users to that final web app, so the user will be accesible from the login web app.
I think an inappropriate solution would be to try to loggin to the 3 different databases changing the connectionString value and set a short connection timeout, but I want to avoid it. I think there must be a better solution and I just need a little bit of lighting. Thanks
There's two approaches:
Shared cookies
Distributed auth
The first method is available only because all of these sites share the same primary domain, i.e. my-platform.com. If that's not the case or it changes in the future, this won't work. You'll need to do two things: every site will need to be configured to use the same auth cookie name and domain (the wildcard .my-platform.com). Then, you'll need to set up a data protection provider on each that pulls from the same source. See this article for more info.
The second method, is more complicated, but also more robust. You'll need to utilize something like IdentityServer4 or a third-party service like Auth0. The former requires more code and configuration, but is free; the latter is virtually drop-in but not free and can become quite expensive, in fact, depending on your usage. In either case, your applications will connect to this distributed auth service for both authentication and authorization. For normal user login, you'd like follow an OpenID Connect workflow, where the user will be redirected to the distributed auth website to authenticate and then will be redirected back to the originating website with a token. The originating website, then, can use this token to request the user claim, and then set a cookie in the normal way.
I have a file server, or more of a personal CDN, which I want to protect against unauthorized access. Assuming that this personal CDN is accessible through https://www.personalCDN.com, and the requests to this file server come from the following domains:
1- https://www.Application1.com
2- https://www.Application2.com
3- https://www.WebSite1.com
In case I want the authentication layer to be cookie-based in a way that, when the user logs into any of these three domains, a cookie for https://www.personalCDN.com would be added to browser, and then it would be used by the main file server, how can I handle this situation in ASP.Net Core 2.x? I've read that, writing cookies for other domains is not allowed in JavaScript, does it apply to Asp.Net as well?
It's not a JavaScript limitation, it's a functional limitation, in general. Cookies are domain-bound. They can only be written on the domain where the response originates. Likewise, a cookie can only be read by the domain that set it. This is for security reasons, and there's absolute no way around it.
What you would need is a SSO (single sign on) solution, which is not a trivial thing to set up. You essentially have one server that acts as the auth gateway. Your other websites redirect users to that server to login, the user logs in on the auth gateway, where a cookie is set for that domain (i.e. auth.domain.com). This keeps the user logged in on the gateway. Then, the user is redirected back to the originating site, with a token. That token is then validated via an API backchannel to the auth gateway. If the token is valid, then the originating website "logs in" the user, setting a cookie for its domain, as well. Rinse and repeat with all your other websites.
For something like your CDN, you would likely need a site hosted on a subdomain of that same domain (since the CDN itself wouldn't be able to coordinate the auth process). That site, then, would set a wildcard domain cookie, which would be usable by the CDN as well.
You can either set up all this infrastructure yourself (not recommended), or there's third-party libraries like IdentityServer that could ease implementation. Additionally, you can outsource the whole shebang to a third-party provider like Auth0, where it essentially becomes your gateway.
This is all with v8.2, with plan to migrate to 9 at a later date
Here's what we're looking into. To access one folder, users would need have AD authentication, for two other folders, user would need to authentication via Kentico's user management. The rest of the site would be wide open.
We also need to ensure any bookmarked URLs send the user to the correct authentication method, if applicable.
I'm digging further in to the documentation for this too.
Yes this can happen. You'd need to enable/setup Mixed Mode Authentication within Kentico.
Secondly, for ensuring proper access to specific nodes in your site, I'd default to whatever more pages need; either require authentication or not. So if the majority of your pages required authentication, then on the master page level in the Properties>Security, set Access to require authentication. This will then propagate through the rest of the site.
For each of the nodes which are "public" simply go to the parent node Properties>Security and set Access to not require authentication.
My company is re-writing its e-commerce site as a single page application using the new Web API / SPA features in MVC 4. We're not sure about the best way how to handle authentication.
Specific questions:
How do we handle both encrypted and non-encrypted communication? Clearly, we need to use HTTPS for the login, account, and checkout AJAX, but we'd like to use HTTP for browsing the catalog in order to avoid expensive SSL handshakes that would slow the whole site down. Is this even possible for a SPA, or are we stuck with HTTPS for everything?
What sort of authentication should we use? Primarily our site will be accessed from a web browser, so cookies may be fine. But down the road, we may want to make a custom iPhone app. Is Basic Authentication, OpenId, or OAUTH preferable? If so, why?
If we go with Forms Auth and cookies, will the redirect issue be fixed for the release of MVC 4, or do I have to use the haack?
If we go with Basic Authentication, how do you do persistent sessions, so that users don't have to log in every time they go to the page again.
Which authentication methods are well supported by ASP.NET MVC 4. It'd be ideal not to have to write a lot of specialized code.
Thanks in advance
1. How do we handle both encrypted and non-encrypted communication? Are we stuck with one protocol, https, with a spa?
You are not stuck with one protocol. With a spa you can use ajax to communicate over http or https, whichever one you choose at any given time. I would use https for anytime your are sending sensitive information like a persons name or their birthdate or login credentials.
Once a user logins to your site over https then your server can set a forms authentication cookie for that user. This cookie should be an encrypted value that ties their session to the server. You must be aware that if the rest of your site is using http then you have the risk of this cookie being passed over the wire in plain text. Even though the contents of the cookie can be encrypted, using an encryption algorithm of your choosing, a malicious person can steal this cookie and jack your user's session.
This might not be a big deal to you though if they are only allowed to browse the site and create a shopping cart. Once the user is ready to checkout then you should re-authenticate the user, over https, as a sort of double check to make sure they are not a malicious user. Amazon does this.
2. What sort of authentication should we use?
Well, that's all a matter of what features do you want your site to have.
OAuth is for exposing webservices which you can allow other sites to call with delegated access. What this means is that if you have a user who wants another site (site x) to be able to access features on your site for their profile. The site x can redirect the user to an oauth endpoint on your site which will authenticate the user. Your oauth endpoint will ask the user if its okay that certain features are shared with site x and if the user agrees a token will be generated. The user passes this token to site x where site x will make server to server calls to your site. Site x will present the token in the calls so the calls to your services will be a delegated access call. OAuth is a way of provisioning other sites to make delegated access to your services. I hope i was able to explain that clearly.. I'm not always good at this.
OpenID is not a very secure way of handling authentication its more of a convenience so that users don't have to be hassled with registering an account with your site. Because OpenID is completely open you are trusting another provider to validate your users. If the third party provider's user store is compromised then your users are compromised also. It's an example of a voucher system where you are basically saying I will trust who you say you are, if you can have an OpenID provider vouch for you.
Another solution is WS-Federation. WS-Federation is if you have multiple sites and you want to have 1 authentication provider that you trust. This authentication provider can be yours and basically all your sites say if you want access to my site then you have to first be authenticated with my authentication provider. This authentication provider can live on a seperate domain and can choose any authentication mechanism it chooses. You are trusting that this auth provider will do its best job to manage your users accounts.
WS-Federation can be overkill though if you only want authentication on your site and don't have multiple sites. In that case I would just recommend doing Forms Authentication and this should be simple enough to do. There are lots of examples of how to do this and microsoft provides many solutions for how to do this. You should look into creating a custom membership provider.
Once a user has been authenticated with your site you should create a forms authentication cookie. This cookie ties the user to their session on the server. This applies to all the scenarios listed above. MVC 4 supports all the scenarios listed above also.
Thanks, and feel free to ask more questions if I wasn't clear enough.
** EDIT 12/1/2017 **
Coming back to this question years later I have learned that relying on cookies for REST based APIs is not a good idea. You don't want to create a session on your web application because it makes your app harder to scale. So, if you need authentication then use HTTPS with some form of authentication (BASIC, DIGEST, Token Based, etc..). So, your SPA client appl will set the Authorization header on every http request and then your web server app will re-authenticate every request.
The main downside of using ASP.NET's form based security is that it assumes you're want a 401 web page when your authentication fails (useless when you're doing an AJAX call) and it's really designed around doing redirects which kind breaks the whole SPA pattern. You can hack around it but it's not designed for the purpose you're using it.
This toolkit may provide an alternative to ASP.NET'as form model.
Not yet sure how mature it is ...
http://www.fluentsecurity.net
Feedback welcome.
I just started working with webapi myself so don't consider my answer authorative. I'm not a security expert though I should be. I ran into the same questions as you did and found, as you did, that there is no authorative answer though - within mvc webapi at any rate. Looking at other webapi specs may give you some inspiration.
The simplest way I came across was of course using SSL. That let's you get away with sending credentials in clear text in the header. Doesn't break rest.
My api will employ SSL all the way but I wanted to double up anyway. So I'm sending an encrypted key in the querystring for all my requests. Pretty much the way cookieless authentication works for a non api asp site, but mvc doesn't play with it so I've rolled my own solution.
On a mobile site, the user would log in, be redirected, to the app with the encrypted key encoded into the js. So he'll initially have a cookiebased auth for the site, and be responsible for it's protection, password saving etc.
Another api consumer would get a more permanent "secret" from a dev site yet to be made and use that to check out a key.
Normally mvc authentication is stateless, meaning the ticket is never invalidated server side. If you controll the client you can just ignore invalidate cookie requests if the server logs you out, and just keep on reusing the ticket. Eventuelly you might want to keep track of your tickets server side, but it's not stateless, doubt if it's restfull, and by consequence scalability taket a hit. But authentication is pretty important so...
Hello and thanks for looking.
Background
I am designing an application that will host certain pieces of information/data for third-party websites via an API and must be accessed via authenticated requests.
Is OAuth the way to go about this or is there something better out there? I will not know the domains of the third-party sites up front so I can not rely on host-headers (which can be spoofed anyway).
Requests to the API will most likely originate in jQuery or regular JavaScript on the client side.
Question
What is the best way to ensure that third-party websites requesting data from my API are who they say they are, and are allowed to access the information they are requesting?
Many thanks!
Matt
OAuth, particularly OAuth 2 (which isn't yet finalized), will likely work well for you. But since the web requests are coming from the browser rather than the web server hosting these web sites, each individual browser will have to be authorized rather than each domain.
So let's step back and ask this question:
Is the data your API will be exposing unique per individual user or unique per web site domain? Or in other words, are you as the API owner going to contractually authorize domains to access your data, or will individual users have data accessible via your API, and those users need to authorize these other domains to access to their own data on your service?
If you're authorizing domains (and not users) then the browser simply cannot be the initiator of these authorized requests to your API. This is because the web server on those domains would have to issue their secret key to the client, at which point they've lost control of it and anyone can make these authorized calls -- not just the domains you've intended to authorize. This is the "you can't trust the client" principle in security.
If you're authorizing users, then each user who visits one of these 3rd party sites will have to go through a one-time setup where the web site redirects their browser to your service to log in and say "yes, [3rd party site] can access my data", after which they're redirected back to that site. After that, any time they visit that site, the site can download a secret key that's unique to that user and can be used from javascript on the client to make these authorized API calls.