I am currently developing some webservices for my system, which will be structured around the following SOA model.
But, I need the opinion of other developers, since I'm currently in a standoff:
The system will be totally integrated, just like google services, where we authenticate ourselves on Gmail, for example, and can access all the other services without authenticating again.
So, the problem is, should I implement a dedicated webservice only for authentication(token based), which all other webservices call this one for login, logout and validate user.
Or should I implement the authentication on all services, one by one?
Which is the best practice in this case?
Related
Im developing a java web application which is deployed on a glassfish server. The web services are used to connect to user databases. Each user has a database. My question is, is there a way to keep track of the user? For example in servlets we use sessions in order to store some user specific data. Is there something similar to it in web services? It seems impractical to have to authenticate the username and password each time the user sends a request to a web service. Thanks.
Web services may also use sessions, however there are good reasons to keep them stateless:
it might be that the clients do not support sessions (cookies), e.g. if your clients are not browser based;
stateless services are easier to scale.
You do not have to use username+password for authentication. You may use JWT (or other kind of access tokens) to protect them.
Auth0 has got nice article on this topic:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
I need to create register/login functionality in CQ5. There are three ways
1 - The register/login functionality should be prepared as web service hosted on a Java Application Server and then we can consume data from web services.
2 - The functionality should be prepared as web service based on RESTFull that hosted on CQ itself since AEM is developed around the REST principal and REST web services is certainly one which will be supported. So I believe RESTfull web services can be hosted with CQ5.
3 - Why do we need web services? I do not think it requires web services since my application is not going to communicate with other application and it dont want to expose any services to outside world. Why don't we create register/login functionality as we do in normal web application. Can we create a OSGI bundle that invoke databases to store user details for register/login functionality?
I would go for 3rd option but my concern is AEM is not the place to build our business logic to carry out functions that are not related to content rendering.
which option would you choose and why? Kindly share your ideas and thoughts. I am just looking for best solution to develop register/login functionality in CQ.
Thanks
I think i am late to the party but it might help someone. Yes, you can very well create rest webservices in CQ and they work well. So, you can take that approach.
The way to go about implementing login/registration would be how it is done OOTB but OOTB is also bad in the way it implements it so you have to make modifications to overcome that.
1) You need to register and Authentication handler with CQ. If you are looking for a sample there is a form authentication handler source that you can look at.
2) We have integrated out Auth handler with Active Directory (AD). Since AD is supported by default, so it is easy to integrate with Auth Handlers.
3) Next you need to create a user login token for which you can look into TokenUtil class of CQ or if you are looking to develop SSO, you can look into SSO code that is packaged OOTB.
I'm building a website using service-oriented architecture (SOA) principles. When users visit the site in their browsers, the interface they see will be composed of resources delivered by several different services on the backend.
My question is how to use OpenID Connect (OIC) to implement SSO so that users log on through the site once and their browsers can automatically retrieve all the protected resources that are necessary.
The main conceptual difficulty I'm having is that everything written for implementing OpenID Connect seems to be oriented toward people creating monolithic third-party clients that authenticate with Google, Yahoo, etc. In my case, however, the client is my web portal and the resource providers are my backend services. Certain OIC concepts don't make sense to me in this context: for instance, the auth grant. Are users supposed to authorize the web portal to access their information the first time that they log on? That would be pretty absurd.
Or Is OIC the wrong tool for what I'm trying to do?
I've recently programmed a REST web service API that allows another website to sign-up for my website remotely.
I've programmed all the necessary validation and filtering in to the API.
My question is, should I now ensure that my own registration form uses the web service API when handling user registration?
The form itself already has the very same validation, but it would seem to be that it would be best if there is only one method that is ultimately responsible for validation/filtering.
That solution doesn't seem to be the best, either, though because I am now making a REST client to touch my own web services API from the exact same website.
The last solution that comes to mind is to put the validation on my user model, and throw an exception up the web services API when validation is triggered. Are there any downsides to this solution?
One of the major benefits of REST is to define a interface that a remote client can access easily with the minimum amount of coupling between client and server. This is very useful when you do not control the client. This allows you to evolve your server interface without breaking existing clients.
The REST interface should really just be a thin layer over your validation and registration logic. In theory it should be easy for you to re-use that logic in your own website without going through the REST api.
Your website is not on a remote machine and you have control over both the client and server portion so you are not gaining anything by going through the REST interface.
I'm going to be developing a REST-ful Web Service for a new public website. The idea behind the web service is to have 3rd parties develop fully functional UIs for the business logic.
For security reasons, I'd like to avoid users having to give their passwords for our service to the 3rd party applications. (Perhaps this shouldn't be a big concern?) Instead, I'm looking to implement some sort of login system on our site that provides an auth token to the 3rd party app but keeps the actual password out of their hands.
This made me think that OpenID might be a potential solution here. It seems to me that it should work: the actual password is handled by the OpenID provider and so it doesn't rest with the 3rd party app. I think that the trouble would probably lie with the various passthroughs, but that should be manageable.
However, there's a surprising lack of Googleable info on this, so I'd like SO's opinion. Has anyone implemented a similar system before? Is it even possible? Is it worth the trouble?
I agree completely that what you want is OAuth; I say that having worked on both OAuth and OpenID systems. I've also been in your boat a few times, having to develop a REST web service api.
For a really good ideas on OAuth, and why it is what you want see these attached article:
These are must read, there are four parts read them all:
http://hueniverse.com/oauth/guide/
the RFC, read after reading above as it can be a little daunting for most:
http://oauth.net/core/1.0
And then finally maybe some code. I have a couple projects hosted that are using Java/Groovy to do OAuth. One is a plain old OAuth client, the other is a client for specific interactions with NetFlix.
http://www.blueleftistconstructor.com/projects/
If you are relatively inexperienced with REST (you haven't built a full scale web api yet) I would recommend that you buy (or better get your boss to) "RESTful Web Services" by Richardson & Ruby. It is an O'Reilly book. I can say that it is one of their better books to debut in the past few years.
It might also help to look at some RESTful OAuth based APIs. The NetFlix API is a perfect example: http://developer.netflix.com/docs
Good luck and happy coding!
So far, I've found 1 worthwhile link:
http://markmail.org/message/utf7js473zqv45hv
This conversation mentions something called "OpenID Exchange" which is right up my alley... but the included link is broken and there's not much solid information on Google for it.
Looks like OAuth might be the ticket: http://oauth.net/
We have been working on a project to integrate OpenID Authentication for SOAP web services. You can find our project at http://code.google.com/p/ws-sandhana/.
You can provide Single Sing On to your web services using OpenID authentication and you can enforce the trusted OpenID Providers and required attributes of the users by defining service security policies.
This is an open source implementation on Apache Rampart which is the security module for Apache Axis2 web service engine. You can find our blog at http://sandhana-project.blogspot.com/ for more information.