Hi David, Andrei
On 19/01/14 16:10, Andrei Shakirin wrote:
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.
It seems the momentum is growing for using OAuth2 as an 'umbrella' for
many types of authentication/authorization combinations.
Specifically, a couple of OAuth2 flows can be used as a possible
replacement for Basic Authentication, I've checked some resources, here
is the first one which looks related:
http://apiux.com/2013/07/10/oauth-2-trumps-basic-authentication/
I think the idea in the end is to suggest that tokens is a better
alternative to passing base64-encoded credentials every time, I believe
in WS tokens are also used a lot
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.
Thanks, Sergey
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?
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
