> -----Original Message----- > From: Andrei Shakirin [mailto:[email protected]] > Sent: Sunday, January 19, 2014 8:10 AM > To: [email protected] > Subject: RE: Can I use a simpler secured service scheme than oauth2? > > Hi, > > I would firstly evaluate HTTP Basic Authentication + SSL. It is enough for > 70-80% of use cases. > OAuth perfectly fit for the situations when resource owner provides access to > restricted resources for third party applications.
Note that I intend this first application to use an initial "conventional" login (even though it uses a proprietary authentication/authorization framework), but most of the secured submissions will be done through Ajax. In that context, I don't think it's practical to use basic auth, as that would mean the credentials would be clearly visible in the browser. > CXF also provides possibility to use SecurityTokenService for validate Basic > Authentication and it supports authentication via SAML tokens. > > For the authorization you can easily integrate container based authorization > (like Tomcat or Spring) or use simple embedded AuthorizingFilter solution. > Look following link for details: http://cxf.apache.org/docs/secure-jax-rs- > services.html. For this first application, authorization will be provided by a proprietary internal framework. > > -----Original Message----- > > From: KARR, DAVID [mailto:[email protected]] > > Sent: Sonntag, 19. Januar 2014 04:09 > > To: [email protected] > > Subject: Can I use a simpler secured service scheme than oauth2? > > > > I may need to implement some secured REST services in the next few > > months. I've deployed a few REST services so far, but none of them were > > secured, so I need to get more familiar with this. > > > > I would assume that I should be looking into oauth2, but it occurs to me > that > > perhaps for at least one particular application, I might be able to do > > something simpler. > > > > For one particular application, I already have a "skeleton" using an > > enterprise-specified login service that presents its own login page and > also > > facilitates authorization features. As a result, I can provide a simple > entry > > point that can read an authenticated user name and authorization > > properties. It seems to me, that in this context, oauth2 is probably not > the > > right fit. I would think that I could now generate some sort of a digest > value > > that I could send to the front-end client (javascript). I'm not sure what > > protections I need to provide for that digest value. Perhaps simply > replacing > > it with new values when the current value is sent on a request might > suffice. > > > > What is a reasonable approach for this?
