I have created a third party api(REST) that I wanted to make public but is only allowed to be accessed from a specific domain. How do I perform domain specific authentication/authorization?
For example, I have an api running on domain say mydomain.com and I wanted to create a JS widget that calls this api, but the widget is used in a different domain say otherdomain.com. How do I make sure only otherdomain.com has access to my api and it is not accessible from say anotherdomain.com.
I could use a api-key to authenticate the api, but I am not sure if that is secure enough as anyone who has access to source of otherdomain.com can copy the script and the api-key and try to access api directly. How can I avoid these kind of security holes.
Using mechanisms like Oauth2 may not help as there is no involvement of a user in this case and hence cannot do user authentication by getting user credentials.
Another idea would be to check for origin header, but it can simply be mocked as well using some reset clients I suppose(or am I wrong in this case)?
Please suggest some ideas to tackle this scenario.
Related
I'm working with a 3rd party REST service that requires retrieving a authorization code grant before issuing an access token. The code will be passed along with the client id and secret in order to retrieve that token. In order to get the code, you have to type the username and password in the form and click the allow button in order for the code to be generated in the redirect uri.
I don't think it's possible, but can this be done with Spring/Java purely using code and not having to go to the browser to retrieve the code?
Your 3rd party REST service needs to provide this functionality (and likely guidance in their API docs). If they do provide it....then yes you can do it entirely in your java code.
I currently have a website set up with Spring MVC and Spring Social so users can sign in with Facebook and Twitter.
Now I want to authorize my Android client to access my third-party web site, with Facebook (or Twitter) credentials. As stated here, this should be possible. But he does not continue to say how. Can anyone get me on the way with this? Just give me some basic outlines of how to do this. I'm really stuck here...
I'm actually in the middle of working on a project which needs to do the same thing. I implemented Spring Security & Spring Social for the website and also needed to allow for the iOS and Android apps to connect via the social sites as well.
Here's what you'll need to do:
Implement the device-specific APIs into the development of your app's projects. So, implement Facebook, twitter or whatever else as you normally would on the devices. You'll be doing the actual authenticating process there.
Implement a special URL for your apps to sign in via the social services. For example, http://yousiteapi.com/services/auth/socialSignin. You're going to need to pass ALL the parameters to this api that would normally get written to the UserConnection table implementation - providerId, userProviderId, authenticationToken, secret, etc. If a provider doesn't use one of these, just pass in null or a empty var.
Within this controller, you're going to need to reference both your implementation of the spring Social SignInAdapter AND the ConnectionSignUp classes along with your implementation of the ConnectionRepository and UserConnectionRepository and basically reproduce the whole signup process. First, you'll need to decide which provider it is via the providerId you pass back and use the provider's consumerKey and consumerSecret to implement the specific ConnectionFactory you'll need. Then, use the data you passed in to create the ConnectionData object. With the ConnectionData object, you create the actual Connection object.
Now is where you replicate the logic of the normal Spring Social login: First, use your reference of the UserConnectionRepository and call the findUserIdsWithConnection() method to see if the user has previous logged in. If not, call the ConnectionSignUp.execute() method to create the user.
Finally, you just call your SignInAdapter.signin() method to sign the user in. Don't forget to set your response to OK so your app knows this was a success.
Wow, that sounds like a lot. Actually sounds like more than it is. Hope this at least helped to point you in the right direction.
I'm building a single signon app and I'm wondering if it's possible to authenticate a user within a completely different website without using oauth, "not a possible solution". I'm currently able to do this by copying the other websites login form into my page along with the post url, hidden field, username/password field. I would much rather do this behind the scenes if possible where credentials wouldn't be exposed. I'm wondering if something like httpclient would be able to accomplish this task.
Any suggestions would be appreciated.
Yes, this is theoretically possible. You are trying to use the other web site as an authentication provider. You need to find out what authentication services the other website offers - you could try federated authentication, LDAP-based authn, kerberos, etc., but if the site you want to authenticate to doesn't support any of these, then you aren't going use any of these protocols.
I have made a Java EE 6 application where a user can browse a set of questions, add new questions and so on. The user can optionally log in so that he/she gets "credit" for adding the question or reporting it as bad.
Now I want to make a iPhone application where the user can do pretty much the same. So the answer is web service I assume. I have not worked with web service before but I see there are at least to alternatives: SOAP and REST.
Which one should I choose? I want the user to be able to log in from the application as well a as browse the questions in the database...pretty much many of the actions you can do on the web site.
I don't know much about the security and overhead they introduce.
Also I want the user to be able to retrieve the list of questions thorugh the web server and have the option to save it, so he/she won't need to have internet unless he/she wants to update it. Can I achieve this with both web services?
REST has less overhead than SOAP (WSDL contract, XML messages, supporting frameworks) so when the client is a mobile device REST seems more suitable. You could use JAX-RS (Jersey) to easily create REST services on the server side. The client request consists of the url structure and/or parameters like http://yourserver/questions/view/342 (to view question 342) or http://yourserver/questions/search?q=REST+vs+SOAP (to search for questions about REST vs SOAP). The response can be anything you want, but XML or JSON is pretty common.
Choosing REST means you will be leaning heavily on the HTTP protocol. For security a common approach is to use HTTP Basic authentication in combination with https. Basic authentication means you add an 'Authentication:' header to your HTTP request containing a Base64 encoded username:password pair. Note that Base64 does not encrypt anything, it just obfuscates. To avoid eavesdropping you need to use at least https meaning requests are encrypted using the server's public key. These requests can only be decrypted with the server's private key. To use https you need to set up the server with a certificate. If you want to avoid warnings about the certificate being 'untrusted' it needs to be issued by a recognized SSL certificate provider. For testing you can just generate it yourself.
Finally you asked about saving a list of questions for offline usage. This is a concern of the app, not of the service. To do this you need to store the retrieved data on the device and access that data if the device goes offline. I am not an iPhone developer, but I can imagine you could use a flat file or some lightweight database to store the data. When the device is offline, the app component that retrieves data should switch from network access to local storage access. Also some app functionalities like adding a question might need to be disabled. If you don't disable these, you would need to temporarily store any data entered by the user and send it to the server when the device comes online again. This could be a bit tricky to get right so my advice would be to leave this for later.
You can take a look at this previous SO post for some guidance. I would recommend using REST, it seems to be less messy than SOAP and Java has support available for it as shown here.
Through the use of annotations, you can simply created a facade to which users will connect. In turn, this facade will call the relevant logic which I am presuming you already have.
Well on a simple search REST vs SOAP, you will eventually get to this
There are plenty of other articles and even in-depth research papers, so it's only a matter of - do you really want to get serious with your research VS not really
Good luck!
Short answer: Yes, you can achieve that with web services.
Web services are only a facade to your system - they can expose (or not) any behavior you want to. If you have security concerns, you'll have to approach them anyway in both methods.
Personally, I'd use a RESTful approach as its usually simpler to implement and use. From Wikipedia:
A RESTful web service (also called a RESTful web API) is a simple web
service implemented using HTTP and the principles of REST. It is a
collection of resources, with four defined aspects:
the base URI for the web service, such as http://example.com/resources/
the Internet media type of the data supported by the web service. This is often JSON, >XML or YAML but can be any other valid Internet media type.
the set of operations supported by the web service using HTTP methods (e.g., GET, >PUT, POST, or DELETE).
The API must be hypertext driven.[11]
So you'd have a URL, say http://mywebsite.com/users and perform HTTP actions (GET, PUT, etc) on them. A GET request on /users/17 could return user 17, for instance, while a POST request on it would update said user.
As for login, when your users "log in" you would call a GET method that sends username:password (probably encrypted) and returns a login token. Every time the user executes an action, you would send said token with the request as an additional parameter.
Here's a scenario:
I have a java front end (RCP/SWT) app which currently has no authentication support.
I have to however, add security to this application so that it gets deployed in different enterprise envinronments. I have a few approaches which I thought I would share with you all here and take your inputs. Please note that there are no strict requirements yet, so.. I would like you to consider typical and non-typical enterprise network security models.
Approach 1
Create a 'Security' webservice that
the thick client would invoke, on startup.
The client queries the security for the current authentication mode and receives the implementation class of the authentication as a soap attachment. The class received, will not have the logic for authencation, rather it would just describe the UI and the events on the UI. (The client could make use of a GUI toolkit such as Thinlet?)
Once the class is loaded, a UI relating to the currently set authentication method is displayed to the end user.
Advantages:
This approach lets me handle different authentication schemes. For instance, if the app has to authenticate against user names and passwords stored in a database, a screen with UserName and password fields would suffice. However, say the user were to do a network logon that would involved typing in the network name, the UI would contain three fields. If the security model at the client network dictates ntlm/SSO based authentications, the user won't see a UI. This will also leave scope for future authentication methods - for instance, supporting a captcha specific logon screen/ biometric stuff / whatever.
Approach 2
KISS (Keepin in yea.., Simple)
User name and password are usually the only two credentials required by all of the known authenticating mechanisms?
Have the thick client query the webservice and let the webservice handle the entire authentication process.
I am not sure how realistic/feasible/commonly used the above mentioned approaches are. Appreciate your help.
I'd certainly not recommend transmitting class definitions as SOAP attachments. A network classloader would make more sense, but is still not needed in your situation.
Put in the client what belongs there - the UI. Have the multiple screen types ready (i.e. defined as classes) on the client and activate each of them depending on a single value passed by the server. For example if AuthenticationType.CREDENTIALS is passed, go for username/password. If Authentication.SMART_CARD is - go for smart card.
If you want to distribute the application and later implement different auth screens, then use Java Web Start. Thus all clients will be guaranteed to be running the latest version.
After knowing that your requirements impose some limitations, take a look at this network classloaders article.