I'm starting to create an iPhone/Android app that will need to use Plone users (i.e. register on the website and then enjoy the app on your mobile).
What's the best approach on doing this? I've seen some apps using OAuth or other techniques, which ones currently supports Plone4 (4.0.3 exactly).
I have the users on a LDAP server (OpenLDAP) but even that I still have to log them on Plone to be able to send and retrieve data from there to the mobile phone.
You have 3 options, and what you choose is dependent on what your skills are and how much time you are willing to invest:
Basic auth
Have your user enter a username and password into the app, and just use HTTP BasicAuth headers to access the site. Plone supports Basic auth authentication out of the box.
This is not the most secure method; passwords are basically sent base64-encoded, so you may want to use HTTPS to communicate with the server. A good idea in any case for authentication anyway.
Cookie authentication
Send a POST request with __ac_name and __ac_password items to '/login_form' on your Plone site, and capture the Set-Cookie header on the response, containing the __ac cookie. That's a tk-auth authentication token you can use on any subsequent request. This is a secure cookie, but any attacker sniffing the HTTP communication stream could re-use this, so again HTTPS is the secure way to communicate.
OAuth
Plone does not (yet) support OAuth out of the box, but integrating with python-oauth should be trivial. This would most likely require a PluggableAuthSystem (PAS) plugin to be written.
Related
I have a cli (which use a rest api) which needs authentication for use.
As of right now, it supports a token auth. This token is generated at the server on a request with username and password and given as the response.This is not ideal (due to man in the middle attacks) and I am looking for a better protocol to use to generate the tokens.
Users will use such a protocol from a cli, and may or may not have access to a browser on the same device (Though a protocol that requires opening a website is not a problem)
The OAuth device flow seems to be a very simple to use flow, but it is meant
for authorization and not authentication. I also do want to support OAuth as that will require a lot of work, and frankly not what I need.
What is the standard or recommended protocol to use in such a situation?
MITM should not be an issue if your server and app are properly securing the connection. There is nothing really wrong in using a username+password to connect to your backend services. After all, when you're logging into the site you're sending an HTTP request with your username and password to a backend the same way your cli app would do it.
But OAuth indeed can a better fit for cli app:
it's easier to revoke the stolen OAuth token than to force user to change a password,
an app doesn't have to deal with user credentials (although OAuth credentials flow is also exists),
it gives you flexibility when creating new tokens. For example, you may want to issue short lived tokens only to force the user to re-login each time the app is used or you may want to use long-lived refresh tokens.
As you already mentioned, OAuth doesn't handle authentication but you can use your current login flow to verify user credentials and issue an OAuth token (how exactly do that is a separate topic).
I don't think there is a special protocol targeting authentication in cli apps. In any case the app would need to send some secret to a backend. One of the possible solutions is to use OTP (e.g. SMS or email code). In this case you send the code the same way as you would send a password but it is better protected against MITM attacks because a code cannot be used more than once.
Someone to explain please (hopefully with simple words for newbies) why a web application built upon a RESTful API can be CSRF exempt?
I received such assertion after asking: Serializing FormView data in JSON, but honnestly I can't figure out why?
Thanks in advance
CSRF or Cross Site Request Forgery, in layman terms, is meant to allow only selected sources(your own website) to submit data to particular url. It prevents misuse of your functionality by other websites or robots.
Say, I have an url for registration, /registration/, but I don't want to allow external submission of POST data to /registration/. So, I would provide a crsf cookie(depending on host and other stuff) when GET request is issued for /registration/, and ensure that same cookie is provided with POST request. This will ensure that users who have requested the registration form(i.e. genuine web users, not robots), would be able to register. It is not completely full-proof, but ensures some level of security.
Now, We don't use CSRF in API's due to following:-
Technically, CSRF is stored as cookie, since browser is not the intended client of API's, it is of no use.
Secondly, API's are supposed to use specialized client and user authentication, thereby eliminating the need for using any CSRF protection.
Thirdly, Restful api's are supposed to be stateless, therefore the order of API calls should not matter, which is essential for working of CSRF.
Note:-
If you have frontend framework like Angular or intend to use api's on browser too, then it is perfectly ok to use CSRF. In that case you are suppose to write two types of authentication for your apis.
Token Based Authentication - for non-browser clients
Session Authentication - for browser based clients (With csrf)
In this case, any request to api must authenticate with atleast one of the authentication.
According to owasp.org:
Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user's Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.
This is not an issue for REST Web services because either:
1) you usually want your service to be accessible from multiple applications (Mobile app, browser, etc.)
2) you have to provide a direct authentication for each request, so this kind of attack is not applicable for REST services. The authentication is done by your application (let's say javascript) and no directly by your browser (sending the session id), so even if a malicious application redirect the user to your webpage, it cannot automatically trigger your javascript function to perform the request (and the authentication).
I would like to build my own REST app.
I'm planning to use oAuth as a main auth approach.
The question is: Can I use login and password as client_id and client_secret (in terms oAuth spec) ?
I don't have any third side applications, companies, sites etc... which will authenteficate my users.
I have my own REST server and JS-application.
Whole site will be made in usual(RPC) approach, but some private part will be done as RESTfull service, with enough stand-alone JS application.
UPDATED: I'm not sure that I even need full oAuth support. It seems to me that I can ask login and password on https page and then generate some token. Later i could use it to check is this user authenticated already or not. But in this case this oAuth become almost the same what we have in web aplications. I do not need oAuth to athorize users ?
I'm not consider HTTP(s) authotization because i don't want to send evrytime user and password to server.
No.
One if the main reasons OAuth exists is to allow integrations without users compromising their usernames and passwords.
If you plan on using username and password, look into xAuth as an option if you still want to sign your requests. More info: https://dev.twitter.com/docs/oauth/xauth.
But you could likely just as well go for HTTP Basic Authentication. At least if you publish your API over SSL. More info: http://en.wikipedia.org/w/index.php?title=Basic_access_authentication
I think you might get a better answer on the security site. See, for example, this question.
In any case, you need to start with a detailed assessment of what attacks you are trying to prevent and what attacks are "acceptable.". For example, if you are using HTTPS then you can probably accept the remaining danger of a man-in-the-middle attack, because it would require forging an SSL certificate. It is harder to say in general if a replay attack is acceptable.
One reasonable solution would be to create a time-limited temporary token by having the user authenticate over HTTPS with the username and password, generating a secure token with an expiration date, and then sending that token and expiration date back to the client. For example, you can create a (reasonably) secure token by taking the SHA1 hash of a secret plus the user name plus the expiration timestamp. Then the client can include the token, the user name, and the authentication timestamp in future requests and you can validate it using your secret and your clock. These need not be sent as 3 parameters; they can be concatenated into one string user|timestamp|token.
Register your application with SLI. SLI grants a unique client ID and a client secret that enables your application to authenticate to the SLI API. You must also register the redirect URI of your application for use in authentication and authorization flows.
Enable your application with specific education organizations so that the application can be approved for use in those districts.
Configure and implement the appropriate OAuth 2.0 authentication and authorization flow in your application, which includes managing sessions and authorization timeouts.
I need secure Restfull services in the provider. I want that the user must have the authorization for use the REST service and I can generate use stadistic or simply dont allow call the REST services if isn´t a register developer.
I have been thinking about that the user send the email and password in the URL (http://autor.derf.com/api/search/email?=dsdfd#gmail.com&passwd=dasffsdf;) but isnt very safe.
Also I have read about oauth 2.0 but the documentation is very very bad for Java.
Are there any other way to have an RESTful api with authorization?
I want a Restfull API access by Iphone, Android, Windows Phone and web
Thanks in advance ;)
If you plan to write all the clients for the service yourself (iPhone, android etc) then sending email and password is a decent alternative, as long as the provider communicates over a secure transport layer (e.g SSL/HTTPS).
You can always add support for OAuth 1 or 2 later if you feel that you want to make your APIs public. (The whole idea with OAUth is to protect user's passwords, and also to get a more fine grained control over which APIs a client can use, and for how long).
But, in your case I would at least consider using basic authentication, in which a typical HTTP request looks somewhat like this:
GET /path/to/api HTTP/1.1
Host: www.example.com
Authorization: Basic aHR0cHdhdGNoOmY=
The hash after "Basic" is simply base64 encoded "username:password", or in your case "email:password". If anyone intercepts it, it is easy to simply un-encode to get the plain text user credentials. So HTTPS is a must.
» More information on basic authentication at wikipedia.
I have an MVC3 web app that does auth to a customization of StarterSTS. I require the realm to be known and the authentication to require SSL.
It works, great.
The problem is when the user lands back onto my website they are browsing with https. This isn't really the experience I want. My site is not a bank or anything of the like. I feel the authentication conversation should be secure (I think) and the token encrypted (I'm sure). But if I manually change the url from https to http on my replying party web app after authenticating it says I'm not authorized.
1) why?
2) Is it possible to fall back to http ? or ... Should I not require https for the authentication, but leave the token encrypted?
Well - what's wrong with SSL?`
The token should be always transmitted using SSL - even when it is encrypted, it could be replayed etc.
Also the resulting session token needs to be protected. So I would go for SSL (easy to setup) and not worry about possible attacks that result from not using it (hard to implement).
That all said - you can turn off the SSL requirement on the wsFederation (requireHttps="false") and nested cookieHandler (requireSsl="false") configuration element.