You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "KARR, DAVID" <dk...@att.com> on 2014/01/19 04:08:56 UTC
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?
Re: Can I use a simpler secured service scheme than oauth2?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David,
Please check http://cxf.apache.org/docs/jax-rs-oauth2.html
I think Apache Oltu may also be used with CXF
Thanks, Sergey
On 19/01/14 19:27, KARR, DAVID wrote:
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Sunday, January 19, 2014 10:58 AM
>> To: users@cxf.apache.org
>> Subject: Re: Can I use a simpler secured service scheme than oauth2?
>>
>> 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/
>
> This looks like a very good fit for what I need to do. Are there any examples for doing this with CXF?
>
> It also occurs to me that I'll have to map the security tokens I send back with the authorization info I get from the proprietary authorization framework, so I'll know what auth is associated with later requests.
>
>> 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
>
> For the old-style "form post submit" web architecture, where authentication is associated with a session, basic auth can work. It's not practical for Ajax requests not associated with a session.
>
>>> 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:dk068x@att.com]
>>>> Sent: Sonntag, 19. Januar 2014 04:09
>>>> To: users@cxf.apache.org
>>>> 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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
RE: Can I use a simpler secured service scheme than oauth2?
Posted by "KARR, DAVID" <dk...@att.com>.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Sunday, January 19, 2014 10:58 AM
> To: users@cxf.apache.org
> Subject: Re: Can I use a simpler secured service scheme than oauth2?
>
> 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/
This looks like a very good fit for what I need to do. Are there any examples for doing this with CXF?
It also occurs to me that I'll have to map the security tokens I send back with the authorization info I get from the proprietary authorization framework, so I'll know what auth is associated with later requests.
> 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
For the old-style "form post submit" web architecture, where authentication is associated with a session, basic auth can work. It's not practical for Ajax requests not associated with a session.
> > 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:dk068x@att.com]
> >> Sent: Sonntag, 19. Januar 2014 04:09
> >> To: users@cxf.apache.org
> >> 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
Re: Can I use a simpler secured service scheme than oauth2?
Posted by Sergey Beryozkin <sb...@gmail.com>.
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:dk068x@att.com]
>> Sent: Sonntag, 19. Januar 2014 04:09
>> To: users@cxf.apache.org
>> 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
RE: Can I use a simpler secured service scheme than oauth2?
Posted by "KARR, DAVID" <dk...@att.com>.
> -----Original Message-----
> From: Andrei Shakirin [mailto:ashakirin@talend.com]
> Sent: Sunday, January 19, 2014 8:10 AM
> To: users@cxf.apache.org
> 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:dk068x@att.com]
> > Sent: Sonntag, 19. Januar 2014 04:09
> > To: users@cxf.apache.org
> > 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?
RE: Can I use a simpler secured service scheme than oauth2?
Posted by Andrei Shakirin <as...@talend.com>.
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:dk068x@att.com]
> Sent: Sonntag, 19. Januar 2014 04:09
> To: users@cxf.apache.org
> 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?