I am working on the WCF REST Service project. The WCF REST will be set on the IIS. The service is to update the database in SQL server. The updated store procedure will get the login username and look for the id on the user table as a parameter. Therefore, the connection to SQL server must use the client’s username and password; I am not able to modify anything on SQL. The client may use website or Cell Phone to consume this Service. I shouldn’t ask the user for providing their username and password on every request in the same season. Does anyone give me an idea or example or link how to deal with this issue?
Thanks.
It sounds like you need some authentication mechanism between the client and the server. How to best accomplish this will depend on the client technology. If you use ASP.NET you could consider one of the ASP.NET authentication mechanisms (e.g. forms authentication). Please check out something like: http://msdn.microsoft.com/en-us/library/eeyk640h.aspx. This handles session state in e.g. a cookie or by appending url info. An other and perhaps more cool solution is to use OpenAuth which makes it possible for users to authenticate with their existing e.g. google/twitter accounts or similar. Please check out http://www.dotnetopenauth.net/. I would not recommend writing your own authentication mechanism, but encourage you to use one of the existing frameworks.
You could save the information in session state.
Here is some info on using session state http://msdn.microsoft.com/en-us/library/ms972429.aspx
Or you could store it in the cookie http://msdn.microsoft.com/en-us/library/ms178194.aspx
Related
I am attempting to make a website's back-end API (I want to make the back-end independent of the front-end so I'm only making a server-side API for now, abiding to RESTfulness as much as possible). I haven't done this before so I'm unaware of the 'best' & most secure way to do things.
How I do it now:
Some parts of the API should only be accessible to a specific user after they login and up to 24 hours later.
To do this, I am generating a random Session ID whenever a user logs in (I'm using passwordless logins so the user is assigned that ID when they click on a link in their email) on the server side, which respond by sending that session ID to the client once. The client then stores this session ID in localstorage (or a file in disk if the client is not a web browser).
Next, I store that ID along with the associated email in my DB (MySQL table) on the server side.
Now every time the client want something from my API, they have to provide the email & session ID in the URL (I don't want cookies for now), which the server checks against the ones in the DB, if they exist then the server responds fully else responds with an error.
After 24 hours, the server deletes the email/session ID pair and the user has to login again (to generate another session ID and associate it with their email).
Now the questions:
Is my method secure or does it have obvious vulnerabilities? Is
there another battle-tested way I'm not aware of?
Is there a better way for the client to store the session ID (if
they are a web browser)?
What is the best way to generate a unique session ID? Currently I
generate a random 16-char string that I set as the primary key of
the session-email table.
Is using a MySQL table the most performant/best way to store session
IDs (given it will be queried with each request)?
Do I need to encrypt session IDs in any way? Is it secure for the
client to send it as a 'naked' URL param?
Sorry for having too many questions in one post but I think they're related by the single scenario above. If it makes any difference, I'm using F# and I expect my client to either be an android app or a web app.
Your REST API MUST not know anything about the REST client session, not even the session id. If you don't want to send a password by every request, all you can do is signing the user id, and the timeout, so the service can authenticate based on the signature. Use JSON web token: https://en.wikipedia.org/wiki/JSON_Web_Token
You can have a server side REST client, which can have the session your described. The question is, does it really worth the effort to develop a REST service instead of a regular web application? I am not sure in your case, but typically the answer is no, because you won't have any 3rd party REST client and your application does not have enough traffic to justify the layered architecture or it is not big enough to split into multiple processes, etc...
If security is important then you MUST use a true random generator algorithm or hardware. https://en.wikipedia.org/wiki/Random_number_generation#.22True.22_vs._pseudo-random_numbers It is not safe to send anything through HTTP, you must use HTTPS instead. You MUST use the standard Authorization header instead of a query param. https://en.wikipedia.org/wiki/Basic_access_authentication
i know this is a question that has been asked many time. but im still concerned about best practice when trying to develop secure code in meteor.
i know you can prevent the client from being able to access the database with the command:
meteor remove insecure
my code currently adds, retrieves records by using Meteor.methods() so although the client is not able to insert data into a collection, it can use the Meteor.method() function. im concerned about holding the login details in the database because would this not mean that the client can use the Meteor.method() function to add/get/remove data from the database.
the client being able to call the Meteor.methods() function seems to still keep the same risk doesn't it? or have i coded me work wrong?
if it help, here is a run down of what my work is doing:
application loads
client calls to get username and password from database
client sends login details to external server (over https) to initiate socket.io connection.
step 2 is the risk because it seems to allow the client to get the login details. once it has this, it uses the socket.io.js library and the api to my webservice to login. so meteor remove insecure doesnt seem to have secured it because get methods are still available in the Meteor.methods()?
being able to use these functions are quite crucial to retrieving data from the database, is there a way around this? what would be best practice for communicating to the database without exposing private data to the client?
Meteor's insecure package is just a tool provided by MDG to quickly prototype apps. It is not meant to be runned in a production app and some people think is a best practise to remove it all together from the start.
After you remove this package, if you want to interact with the database on the client using mini-mongo you must create the appropiate allow and deny rules on the collection. Here is the link for the Meteor documentation on this topic. The other way to interact with the database, is as you said, using Meteor.methods().
Meteor methods calls don't trigger allow or deny rules, since they are runned on the server. You must hardwire all the security measures you need on the Meteor Call by yourself. So it can be a security problem if you don't take the time to secure the call.
Regarding authenticating your clients I would suggest you take a look at Meteor's Accounts package. For example you can add this two packages for basic username/password authentication:
meteor add accounts-base accounts-passwords
Then you can just use the methods detailed on the Meteor Documentation.
I hope this helps.
Login
If you are using accounts-password, you can check the source here to see details of how it works. But here's a rough overview of it. When you call Meteor.loginWithPassword, the password is hashed client-side. Then a method is called with the parameters. The password is then salted and checked against the database server-side. If it matches, the client gets logged in. The client then subscribes to their own user data (Meteor.user()). The server only publishes their data. So everyone else's data is save.
Methods
A method executes code server-side. So they are generally secure. But you can of course write insecure methods. Just know, that you can't trust the parameters passed by the user.
I am developing a Rest service with Web API. The service only requires one login credential as it is used by an application developed by a third party. If I use the project template with "Individual User Accounts", I have to have a SQL server running(?), which is an overkill to support a single username and password. How about the LocalDB comes with VS 2013 ?
"Windows Authentication" cannot be used because the service is accessed from the Internet.
What is the proper way to authenticate ?. Are there any "in memory" or config file providers that come with Web API ? I know there is Asp.net Identity package, but It uses entity framework as a provider. Can anyone please suggest ?
You can create a custom store for ASP.NET Identity and it could be memory or a config file. Here is a tutorial on creating a custom store in ASP.NET Identity. I would not put it in memory because you will most likely want to change the password and that would require a recompile and redeploy. Personally I would just use SQL Express or SQL Compact as they take minimal resources and rewriting the data store seems like a lot of work for little benefit in this scenario.
No matter how do you want to authorize the call, the users has to be present in a database or cache to check the validity of the provided user. Microsoft will offer you out of the box a solution based on SQL server or some of their own products.
If you want to implement you own user check, you will probably have to take care of the authentication by yourself. This means that you will have to check the HTTP header by yourself and reject or accept the request by yourself.
My question is, why do you want to use some "in memory" provider? The users has to be somewhere. Why not a SQL express?
I'm currently trying to setup FOSOAuthServerBundle with my Symfony2 app.
Everything seems to be setup and functional, anyway I'm stuck after the installation.
What is the proper workflow with URLs to get the access_token ?
I tried /oauth/v2/auth, but sounds like I need to define a Client object first.
How to create/generate Client ? Clients are always supposed to be created manually ?
FOSOAuthServerBundle doc is great, but seems to skip all the usage workflow. Am I supposed to check the OAuth2 doc for this ?
Thanks !
In short, yes. You should be using the oAuth2 RFC to determine which workflow you want to use. In regards to client registration the RFC specifically states that the means through which a client registers is beyond the scope of the specification (https://www.rfc-editor.org/rfc/rfc6749#section-2).
With that being said I can give you some insight into how I did this. My application is a mobile phone application that connects to several services running on various servers. I'm also using the Resource Owner Password Credentials Grant.
The way I approached this was: when the application loads, the first thing it does is to check if it has an oAuth2 client id. If it doesn't, then it POSTS to a create client endpoint I've setted up with the meta-data I need. The endpoint validates the POST, creates the client and returns the client information. The application stores the client id and the process doesn't have to be repeated the next time.
Application loads;
Application checks for oAuth2 client id;
If there is one, the process ends;
If there isn't, it posts to http://www.example.com/client;
If we get a 200, store the oAuth2 client id.
I could have also created the oAuth2 client when the user created an account in the application, but I wanted to make the registration process as fast as possible. Creating the client would have added some extra waiting time to the process.
Check this: http://blog.logicexception.com/2012/04/securing-syfmony2-rest-service-wiith.html
It's quite simple to convert to Doctrine, whether you use it.
There's a command-line that does exactly what you need: create a Client!
I'm slowly beginning to unerstand REST and theres one thing thats confusing me .
I understand that most of the things in REST is a "resource" . So i was wondering what kind of a resource would we be referring to in the case of a user signup / login ?
Is it users ? Then does it mean that a POST on users would signup for a new user . If that is the case , then how do i authenticate a user ? a GET on users with an encoded password / username pair?
I'm really confused with this.
I may be COMPLETELY wrong in my understanding given that i'm just starting to understand REST.
Any help is appreciated !
Thanks!
It's a bit of an unusual but common problem for REST. Keep thinking about resources.
When you login you're asking the server to create a session for you to access certain resources. So in this case the resource to create would be a session. So perhaps the url would be /api/sessions and a POST to that url with a session object (which could just be an object consisting of a username or password and perhaps the UUID) would create a session. In true REST you'd probably point to a new session at /api/sessions/{UUID} but in reality (and for security purposes) you'd probably just register a session cookie.
That's my own personal approach to login forms if I were to implement them myself but I always tend to use Spring security for that job so this requirement never really takes much consideration.
I am working on something similar and this is the solution I have taken so far. Any suggestions welcome :)
I have users exclusively for singup and account modifications.
GET /users/{id} gets a user for the profile page for instance
PUT /users creates a new user with username and password. In reality this should send an email with a link to somewhere that confirms the signup with a GET method.
POST /users/{id} modifies the user (for example change password)
DELETE /users/{id}
For authentication I tend to think that the resource I request is the token or the authentication. I have tried to avoid the word "session" because it is supposed to be anti-RESTful, but if you are just creating the illusion of an actual server-side session for your clients, I guess it is fine.
PUT /authentication/ with usename/password returns Set-Cookie with the pair user_id / hashed value. Maybe it should be POST. Not sure
DELETE /authentication/{user_id} just deletes the cookie and the user is signed out. Maybe instead of user_id it should be a unique token_id.
Resources can be created, read, update and deleted using a restful approach, see e.g.:
https://cwiki.apache.org/S2PLUGINS/restful-crud-for-html-methods.html
So if you'd like to administrate you users this would be the restful approach to do so.
If you'd like to authenticate the users which you have in your administration dataset you need
to design or select a restful authentication mechanism see e.g.
http://de.slideshare.net/sullis/oauth-and-rest-web-services
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
For a jumpstart on these issues you might want to check out dropwizard:
http://dropwizard.codahale.com/
A resource may have one URI or many
but One URI will have exactly one Resource
Therefore, When Authenticating a user, you are addressing a user who is already registered
While when registering, you are addressing the user (resource) which is yet to be registered.
All you need is a way to process it to your SERVER.
THIS is an example taken from SUGARCRM REST web services implementation.
REST is like http requests to your SERVER.
For eg, when implementing REST Web Services.
Every REST Request is going to same File say
www.your_domain.com/Rest.php?json={your_json_method:'method',params:'watever'}
Where in Json is the request you are sending as a parameters
Requesting to authenticate a user
{method:'SignUp', username:'abc', pass:'pass', confirm_pass:'pass'}
Requesting to register a user
{method:'Login', username:'abc', pass:'pass'}
by this way you can have as many params as you want
Remember JSON is not necessory to be used. you can use simple get params for your query