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.
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. Regards, Andrei. > -----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?
