I wanted to implement a certain architecture that decouples my rest API from a web server that would be used as an agnostic template engine such as DustJS. My back end rest API would be built using service stack.
The main thing that I like about service stack and NodeJS is that they both provide a way to authenticate but I only need a central way to access credentials for granting access to API calls as well as restricting certain content on my views.
The application I want to develop is a subscription based dating website, so that presents me with a few problems. The parameters involved are roles, groups, authenticate and authorize. It's easy to implement on service stack but I am confused with mainly how the front end could get access to that information.
How would I implement a scenario where the front end retrieves credentials once and does not have to keep making API calls to check the DB or Cache to see if it checks out? Do I need to implement a different method in handling clients who wish to remain logged in, or does that typically get solved just by setting a time stamp value?
Thanks for your time everyone.
Sessions are just AuthUserSession POCO's stored in a Cache
The way Authentication works in ServiceStack (and most web frameworks) is that when a User successfully Authenticates, an Authenticated UserSession is created for that User and stored in the registered Caching Provider you've registered in ServiceStack's AppHost. The session id for that the Authenticated UserSession (aka AuthUserSession) is then stored in the Users cookies under the ss-id Temporary and ss-pid Permanent cookies.
Session Cookies re-sent on each request
Cookies by design are re-sent on every subsequent request to that domain which is how Server frameworks know which Authenticated User is making each Request by simply retrieving the AuthUserSession from the Caching provider stored under the following key:
urn:iauthsession:{sessionId}
Where {sessionId} is either the Temporary (ss-id) or Permanent (ss-pid) cookie depending on whether the User Authenticated with ?RememberMe=true or not. This also means your node servers can also easily access a Users Session authenticated with ServiceStack by accessing the same cache with the above key format.
Most caching providers are distributed
All Caching providers except for the MemoryCacheClient (default) are distributed which means that each of your load balanced App Servers will naturally be able to tell if the User is Authenticated or not.
Accessing User Sessions is very cheap
I wouldn't be concerned with performance for retrieving the UserSession since accessing a User Session only takes a single cache hit to access the blobbed Users Session at a single key - which is closest to the cheapest network request your Server can do.
Can avoid network requests with a Write-thru Cache
One way you can avoid the single cache request to retrieve a Users Session is with a write-thru cache where when a User is authenticated it is saved in both a local MemoryCacheClient as well as a distributed ICacheClient (e.g. Redis) that way when the request for a Users session is requested it first looks at the local cache and if it doesn't exist will call the distributed cache to fetch it, storing it in the local cache before returning it. The one thing you need to watch out for is to synchronize any changes to the distributed cache with the local caches stored in the memory of all the load-balanced App Servers which you can use something like Redis Pub/Sub to send messages between all the different App Servers.
You have to check SOMETHING. Your website will presumably establish a cookie with the client, and every time the client accesses, it COULD check in the DB that the cookie is valid, but this is possibly wasteful since the max unique users accessing the site within an hour say is probably very small compared to the total subscription list, say 1% for examples sake. So, you could just have a HASH memory cache that checks the cookie session ID, optionally with the IP address of the client if you like that extra security. So use the session ID and optionally IP to find the data, and make sure you store the last access time in the data so you can invalidate this memory cache entry if it's not been accessed for too long, or so you can garbage collect it, and store any other data that you actually need to actually do whatever else you need to do.
If your website becomes large and scales over many machines in a load balanced cluster you can load balance to servers based on client IP, which means this cache will not become unnecessarily large since usually a given client will go to the same server, but if they switch it's fine as your web app can just fall back to loading from the database.
Judging from all I understand JWTs would be solving your problem. Since a JWT-token is not opaque you can do any kinds of validations from it's payload locally, without checking a central session service.
It's not too straightforward, but speaking simplified: "It solved all our problems with sessions"
Auth0 provides a lot of good reads on it. Start here.
Related
When pushing a website update to Azure does the app pool reset? What effects does this have to a user that is signed into the site? Would the user get signed out?
When pushing a website update to Azure does the app pool reset?
Yes. You can check this in the Kudu Debug Console, under Process Explorer. Note how the PID of your application changes.
What effects does this have to a user that is signed into the site? Would the user get signed out?
Signing in with Azure AD (i'm assuming since you don't mention an IdP) is heavily dependant on your token cache strategy:
Assuming you're only using a memory cache for ADAL/MSAL and your app pool restarts —
In this case, the STS and ASP.NET cookie are still in the browser session, your code needs to check the cache and if it looks like a fresh cache, redirect user to STS (Challenge() in ASP.NET). This will be seamless and won't require typing in credentials since the STS cookie was never gone.
If the user session state is also stored in memory (the default for ASP.NET), then you'll lose the user's session state as well (if that holds a shopping cart, you have bigger problems to worry about).
The sensible thing to do is to move to a persistent token cache and a persistent user session store as well. Redis cache is a good choice. SQL is fine too, probably a bit much.
I've read several Stack Overflow threads, I still can't decide what is the best option for my case. And the most secure one.
Here is the story. My webapp is to help users automatically get an overview of some of their data available in some third-party website. I need to store for each user some third-party credentials. Each night or so, my server will connect to the third-party services on the users' behalf and retrieve the required data.
Most of those third-party sites do not implement any API or OAuth mechanism, so I was thinking to do some web scraping.
I've read in many places that storing the credentials in the DB is not a good idea - especially because my app needs access to the password (so it has to be encrypted in such a way I can easily reuse it).
So, I have two options left:
Whenever I access (via webscraping) the third-party service, I store on the server the cookies issued by that service, for future reuse. I encrypt them and keep them encrypted in a DB, and decrypt them only when I need them. The problem is that the cookie can be denied or expired after a while, and so the automatic process wouldn't work any more.
I store the credentials in the environment variables. I will be on Node.js and Heroku. That's an idea I found in another SO thread. But I'm wondering about the security of this idea. Is it really safe? No one can access them but me? And what about if I reach many users. Like 1000 users, with 10 services. That's 10000 credentials to store in the env variables. That doesn't seem like a good idea.
I found two interesting questions on Stack Overflow but they don't fit 100% with my use case.
Security model: log in to third-party site with user's credentials (that gave me the idea in point 1)
Rails storing third party credentials.. Anyone know best practice? (gave me the idea in point 2).
I add another answer because maybe this one will do the trick for you.
You said the main goal of your website is to have an overview of third party applications. But what if instead of updating this overview every night, you update it when the user logs in ? It changes everything, because you could use the user's password (of your website) as master password to encrypt (using AES) all the others.
If you do that, the communications between your server and the clients have to be encrypted with SSL pinning, because an attacker could perform a MITM, get the master password and all the others stored in the DB... (Even if in practice it's very hard because you need to hack the client AND the server)
Storing a lot of data that changes and grows in environment variables will never be practical, no matter if it's secure or not so this is pretty much out of the question, unless if you have a small fixed number of users.
Not storing credentials in the database is a very good advice, but the cookies are credentials and even if you store them encrypted, your app needs to be able to encrypt it to use it. (This is unlike the situation with verifying passwords of your users when you don't need to ever encrypt them, you only need to see if the provided passwords hash to the same values that you have stored).
This is a hard problem because to make it work you need to have some form of credentials (whether those are passwords or cookies) stored and ready to be used unencrypted (even if they are stored encrypted, you need to store the keys to encrypt it as well).
Also, what you are trying to do can be illegal. Mayke sure that you follow the TOC of every service that you're using or otherwise you may face legal trouble.
Plan for the attacker gaining admin access to the server. Your site will be very attractive to attackers, kind of a one-stop-shop for user credentials so you will need very good security of the login credentials.
There are more than two options for storing the credentials:
Use an HSM for the storage or individual credential encryption keys.
Keep the credentials on another dedicated server with no Internet access, 2-factor authentication and limit admin personal. Rate limit the access to this server and add rate alarms. Access this server on a per user credential basis over a non-Internet connection. The credentials will only be available to the Internet connected server in memory as used, not at-rest in a file.
Storing users credentials in a reversible way looks like a terrible idea anyway. But if you really want to store them, I suggest you to use the environment variables solution. But you can improve it. To limit the amount of data you store and don't have 1000000 variables as you said, you can just store an AES encryption key, store all credentials in a DB encrypted with this key, and you just have to get this key (which is in memory) and decrypt the DB. But there is another problem with this solution. As I said, this is stored in RAM memory, so it's not persistent, imagine your server has to reboot for X or Y reason... You will lose the AES key and also the credentials of your users... Moreover, if the attacker performs a memory dump, he will have access to the AES key...
I think the better idea is to store the cookies (in an encrypted way) and when this one expires, you alert the user (by mail, phone, notifications, ...) and ask him to fill his credentials again. But it's not a perfect solution ! Indeed the cookies are a type of credentials and shouldn't be stored either...
My collegues and I want to build a chat application (ReactJS <-> NodeJS), and we have been looking for the best framework to do so. FeathersJS seems undoubtedly the most stable and feature-rich socket.io wrapper.
However, as we want to allow our application to scale up, we have decided to split this chat feature in a different node process than our main node backend.
The chat functionalities still requires authentication and authorization however, and we would like to avoid duplicating authentication for the two services. Hence what we have come with as a solution is to query the main node backend with the session cookie to authenticate the user before letting them use the chat service.
Does FeathersJS establishes long-lasting socket connections or would it establish a socket connection for every message sent/received? In the first case we could proceed with our architecture, whereas on the second we'd have to review due to the high load this would produce on the main backend.
Thanks!
There are several ways of splitting up services each with their own advantages and drawbacks. One generally important thing for Feathers is that there are no sessions, just JSON web tokens. JWTs are stateless and can be read by any server that shares the same secret so there does not have to be a central session store. The two main options I can think of are:
Have a main application that handles authorization and managing all connected clients but instead of having services that talk to the database they connect to separate simple individual API servers in the internal network. This is the easier setup and the advantage is that the internal API servers can be super simple and don't need authentication at all (since the main application is allowed to do everything and will make queries according to the authenticated users restrictions). The disadvantage is that the main application is still the bottleneck (but with a decreased load since it basically acts as a proxy to internal APIs).
Every client connects to every API server they need using a JWT. The JWT is created by a separate authentication (or user) API. This is the more scalable solution since the only bottleneck is retrieving the most up-to-date user information from a common users service (which might not even always be necessary). The disadvantage is that it is more complex to manage on the client side and authentication (at least for JWT) will have to be configured on every server. Due to the statelessness of JWT however, there does not need to be any shared sessions.
I have a main website running on AppEngine. It's on a subdomain like main.example.com. This main application is a content portal for our customers. It offers an Ajax application built on YUI. Customers can upload data to it. Users authenticate using Federated Login.
The Ajax application on it allows users to process the data previously uploaded. To do it it should use an webservice running on other subdomain like service.example.com. The webservice does not run on AppEngine but on our services - it's CPU heavy and built on other set of technologies. It would need to download the data on main application - but the downloading service - like everything on the main application - is behind the authentication wall.
I could programatically always allow the service to download wharever it wishes but I think this can turn into a major security problem.
How can I reuse the OpenID authentication "token" to allow it (the service) to appears to the main application as the authenticated user so it can download data? Or If I can do this what would be the best way to accomplish what I intend to do?
You can't really reuse the authentication token. What you should use is something akin to OAuth, though since you control both ends you can make it somewhat simpler:
Generate a shared secret, accessible by both main.example.com and service.example.com
When a user accesses service.example.com for the first time (no authentication cookie), redirect them to main.example.com/auth?continue=original_url (where original_url is the URL they attempted to access)
When you receive a request to main.example.com/auth, first log the user in the regular way (if they're not already). Then, take their user ID or other relevant credentials, and generate an HMAC from them, using the shared secret you established in step 1. Redirect the user to service.example.com/finish_auth, passing the computed HMAC, the authentication details such as user ID, and any parameters you were passed in such as the continue URL.
When you receive a request to service.example.com/finish_auth, compute the HMAC as above, and check it matches the passed in one. If it does, you know the request is a legitimate one. Set an authentication cookie on service.example.com containing any relevant details, and redirect the user back to their original URL.
This sounds complicated, but it's fairly straightforward in implementation. This is a standard way to 'pass' credentials between mutually trusting systems, and it's not unlike what a lot of SSO systems use.
We have one web application (sharepoint) that collects information from disparate sources. We would like to be able to link users to the main websites of those various sources and have them pre-authenticated. I.E. they enter their credentials for the other sources (which are a number of different types LDAP, AD and home grown!) and we retrieve some information for them, and remember there details (Possibly Single Sign-on to keep em nice and safe). The user can then click a link that will open the full app in another window already authenticated.
Is this even likely to be possible?
Office Server has a Single-Sign-On api as a builtin feature. you may want to look into that. It enables you to register user credentials securely, and to access it at runtime.
You need to act as a web browser acts to different sites with storing credentials (usually in cookies) locally. Use therefore a a proper client library with cookie support. This could go probably for most of sites. There are sites using HTTP authentication, which are also easier to access from appropriate client libraries. The most demanding can be access to SSL websites, but again, most client HTTP libraries cover that nowadays as well.
All you need now is just to prepare your web application to act as a proxy to all those separate web resources. How exactly this is done in Sharepoint, well, I hope others will answer that...
True Single Sign-on is a big task. Wikipedia describes common methods and links to a few SSO projects.
If you want something lighter, I've used this approach in the past:
Create a table to store temporary security tokens somewhere that all apps can access.
From the source app (Sharepoint in your case), on request of an external app, save a security token (maybe a guid, tight expiration, and userid) in the token table.
Redirect to a request broker page/handler in the destination app. Include the final page requested and the guid in the request.
In the broker, look up the security token. If it exists and hasn't expired, authenticate, authorize, and redirect to the final page if everything is good. If not, send a permissions err.
Security-wise, a guid should be near impossible to guess. You can shrink risk by letting the tokens expire very quickly - it shouldn't take more than a few seconds to call the broker.
If the destination app uses Windows Auth and doesn't have role-based logic, you shouldn't have to do much. Just redirect and let your File/UrlAuthorization handle it. You can handle role-based permissions with the security token db if required.