I have been through much of the documentation and examples provided, but Im looking for some inputs for my setup from other users.
I have a some clients (website, iOs/Android apps). These only serves as a shelves and its content will be requested through servicestack, which makes servicestack a central point of my setup.
The client will login through servicestack and get a sessionid.
My question here is, how should i setup servicestack to make sure that the user is validated on each request?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted). Then on each request based on the session id, i check the cache to see if the user exists. If the user exists, the request i authenticated, and if not the user have to login again.
Am i on the right track here, or is there an easier way in servicestack, to support this?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted).
It sounds like you can just use the Authentication/Authorization plugin. Once a user is authenticated (using any of the 'Providers') the user's session is stored in the cache using the key 'urn:iauthsession:[sessionId]' and contains a bool property isAuthenticated. For any Service the requires Authentication you can use the Authenticate attribute.
Related
I'm building a new Web API application using OWIN cookie authentication (ASP.NET Identity 2.2) for security.
I'm new to the whole cookies thing, but I've got a head-scratching problem: How is a logged-in user immediately blocked from using the API if their account has been deactivated (either deleted or locked-out)?
This arises after a startling discovery that if I have a user logged in on a client app, and I delete their user account via a different app, they are still able to access the API (i.e. the [Authorize] filter still succeeds because their cookie is still valid).
Somebody please correct me if I'm wrong, but AFAIK, cookies are not stored on the server, so there is no way to "invalidate" the cookie.
Yes, if the user logs out, they won't be able to log back in again. Also, I understand that setting an expiry on every cookie upon successful login will mitigate the problem.
But what about the following scenario: a system administrator (let's call him JoeAdmin) gets fired or otherwise becomes untrusted and some other administrator locks out his account. If JoeAdmin happened to be logged in when he got fired and became disgruntled, he still has access to the system and can do some real damage.
In this scenario, how could JoeAdmin be blocked immediately?
JoeAdmin happened to be logged in when he got fired and became disgruntled
Also JoeAdmin could have saved the cookie value offline, awaiting for his account to be revoked, and then later restores the cookie value to his browser.
OWIN cookie authentication is not ideal if you ever need to immediately invalidate logins.
This is because all the state information about the user is stored client-side, authenticated with a secret only on the server-side.
That said, you could do something with Oauth2 refresh tokens like here. e.g. have an access token that expires after say a minute, which when expired the application has to use a refresh token in order to gain an access token for another minute.
This way, any revoked accounts are only exposed for a short time. However, you may need to deal with the complexity of out-of-sync clocks on client and server.
Long story short, if you need to secure your system in this way, traditional server-side tokens would be the way to go. They are more secure in this regard.
The risks with using OWIN cookies are very similar to those of using JWT's for authentication. See this comment and the associated question and answer.
I am building an nodejs server and i decided to perform authentication via active directory.
So my first question: is it possible with nodejs? If so, could someone please direct me towards a relevant article/documentation/plugin?
My second question is about the authentication itself.
My server is restful so i basically have to give some form of identification every time i request something from the server.
I though about the next flow:
At the login page in the client, i send username and password to the server.
At the server i authenticate with active directory using the credentials that the client have sent.
Once i receive a response from active directory, i check if it is a valid response and if the login was successful, i also check if the user have proper permissions in active directory to use my services.
Once all that is validated, i create a token for the user.
Every request from the client would have to contain a valid token.
This seems like the most standard way to approach this problem, it is much more simple and secure than sending the username/password with each request and authenticate with active direction every time.
However some thing bother me.
For example: What if the system administrator decides to remove a user from active directory or remove his permissions to use my services? That user still have a token that allows him to access my services.
I could set an expiry to the token, but unless that expiry is one second, the server won't be really at sync with the active directories.
Do you think that tokens is the way to go with this problem? Or should i just do it by sending username and password each request?
Another way is to give a token to the client but on the server, associate that token with active directories username and password. Every request, the server would authenticate with active directory? Is this a good way to go?
Thanks,
Arik
I'm writing this a little bit too late but: I'm creating also a node.js ember app which uses the node-activedirectory. Ofcourse it's possible with node.js: node-activedirectory or ldapjs. I don't know nothing about the second question unfortunately. Yes it's possible to check. You can use authenticate function from node-activedirectory, and then a isMemberOf function. node-activedirectory is working well, so You can authenticate every time, it's note a problem. Yes, if the user is logged, He will be logged until the session or cookie expires(whatever You want to choose), or You can create something like: every time after refreshing page node-activedirectory checks only if user exists. userExists
I hope I've cleared out some of your thoughts.
Greetings, Rafał
So I have got all my auth working in my MVC web site but I want to ask: What is the recommended way to pass the access token around in my application?
So, I click login, a dialog pops up and I log in. My parent window receives the access token and I get some playlists. But what if I go to another page, which would be a completely new request? Do I pass it around on the query string, or in session, or maybe a cookie? I have searched the API documentation for this, but cant find anything about it.
I would say you should store it in the side from which you are making the requests. If the requests are done client-side, then keep the access token client-side. You can persist it using localStorage, as done in the web api player example. That way you can read from localStorage when you need to make a request and use it until it expires.
Then, if you have used the authorization code flow you will want to refresh it, so the user doesn't need to log in every 60 minutes. For this, you will need to make a request from your server, since the refresh process involves sending a secret that you don't want to make available in the browser. You can store the refresh token in the server (e.g. in a database table storing user <-> refresh token) or in the browser's localStorage too, sending it to the server when you want to refresh it.
You could also store it as a cookie, but if the server doesn't need to know about it, localStorage is better.
I think the Identity will be holding all the details about the logged in User. If anything we want extra , we can extend it.
Below link may help :
http://www.codeproject.com/Tips/574576/How-to-implement-a-custom-IPrincipal-in-ASP-NET-MV
I have a tricky problem, i have got a Marionette Application based on a node.js backend which uses express-resource to access the database.
I use a middleware to ensure a logged-in user, if not the user is redirected to a login page which is served by node directly. After login the user has got a session cookie and is forwarded to the Marionette App.
The application doesnt know the user. In order to get the user i wil have to get it via an ajax call. The problem is, i don't know the users id because the session token doesnt contain this information.
My solution is: There are two resources in the api, one to get accounts in general and one to get only the current user. This is a kind of duplication of resources i want to avoid.
How to do this properly?
you can simply add the user id to the session cookie..
btw - make sure your backend accesses only the authenticated user's resources (according to the session) and that you don't have to provide the user id to AJAX calls. maybe you can actually avoid knowing the user id ?
I have developed simple website using Tomcat and Java. Now I'm trying to add authentication to it. I am storing username and encrypted password in database.
How do I validate user on every request to website?
While doing my research I found out that I need to set some cookie, return it to browser if user is authenticated, and then validate it request by checking this cookie in every request I get from user.
Also, how do I manage the session, i.e. create new session for user upon authentication, set timeout, clear session and cookie upon logout?
Web development and particularly authentication/user management is very new to me, so I will appreciate your help.
Thanks.
This will depend a lot upon the language you are using to develop the website and how you plan to handle sessions.
PHP Sessions
Java (JSP) Sessions
ASP.NET Sessions
ASP Sessions
...etc
the list goes on, especially with how to manage authenticating.
The general (pseudo code) for this usually revolves around something of this nature
Depending on the language of course:
User Creates Account (typically an HTML form posting to your server side code)
Account Information Is Stored to the database
Cookie is created with information allowing user to auth in the
future (with cookie duration)
Session is created for the duration of the users login
User leaves the website
User comes back to the website
Website checks for stored cookie
if Cookie is found - check cookie, is the auth still good? (did the
users password change recently? has the cookie expired)
If the cookie is good - create a new session and allow the user into the website
If the cookie is bad - present the user with a login form
Rinse/repeat as the user logs in and out.
Depending on your language you will want to look at different resources, however cookie generation is a pretty simple task and can be easily done with JavaScript and HTML. Take a look at http://www.w3schools.com/js/js_cookies.asp and see if it meets your needs. Note that from what I recall JavaScript only does Cookies, and not sessions.