You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Oliver Wulff <ow...@talend.com> on 2014/02/05 20:56:30 UTC
REST security enhancements
Hi there
For the REST services of the Fediz IDP I'd like to support initially three security use cases.
1) Basic Authentication, Username/Password validated against the STS
2) Basic Authentication, Username/Password validated with JAAS
3) SAML token in Basic Authorization header
In CXF 3.0, each REST security interceptor enforces the security credentials it supports. Therefore, you can't just configure all interceptors like:
org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
The interceptors should not throw an exception but instead assert the token (similar the policy) and finally an interceptor checks whether one token was provided and successfully validated.
Other ideas?
Thanks
Oli
------
Oliver Wulff
Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
Solution Architect
http://coders.talend.com
<http://coders.talend.com>Talend Application Integration Division http://www.talend.com
RE: REST security enhancements
Posted by Oliver Wulff <ow...@talend.com>.
Hi Sergey
Looks fine for me as well.
Thanks
Oli
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Andrei Shakirin [ashakirin@talend.com]
Sent: 24 February 2014 17:54
To: dev@cxf.apache.org
Cc: Sergey Beryozkin
Subject: RE: REST security enhancements
Hi Sergei,
Yes, I think that is useful and pragmatic substitution for ws-policy.
If user like to limit the service for some authentication schemes only, it is possible to configure corresponded authenticationHandlers (for example Bearer, SAML, Basic or Digest).
Basically very similar mechanism as ws-policy based PolicyInterceptorProvider in jax-ws.
+1 from my side.
Regards,
Andrei.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Freitag, 21. Februar 2014 13:40
> To: dev@cxf.apache.org
> Subject: Re: REST security enhancements
>
> Hi
>
> How about this for a start:
>
> http://git-wip-
> us.apache.org/repos/asf/cxf/blob/55a4b7bf/core/src/main/java/org/apache/cx
> f/interceptor/security/DelegatingAuthenticationInterceptor.java
>
> ?
>
> all this interceptor does is it delegates to the authentication scheme specific
> handler
>
> Thanks, Sergey
>
>
> On 19/02/14 12:29, Oliver Wulff wrote:
> > Hi Sergey, Andrei
> >
> >>>>
> > However from my perspective it could be interesting to change
> > "requirements" and "capabilities" for JAXRS endpoint dynamically. That
> > means that all relevant interceptors are prepared and configured, but
> > decision which from them should go into chain for the current message
> > is made dynamically (based on policy language, configuration, etc )
> >>>>
> >
> > I agree that a REST service provider can configure the interceptors with all
> required configurations like keystores etc. Then I see two options:
> > 1) All security interceptors are in the chain which means they don't fail in
> case of one security interceptor fails and a final interceptor will enforce
> security or not based on some configuration.
> > 2) A single interceptor which dynamically check which interceptor is able to
> handle the current request (canHandleToken/canHandleRequest or
> policyexpression). This requires an interface for the security interceptor to
> know which interceptor can handle a request or which security standard is
> supported by an interceptor.
> >
> > IMHO, I'd prefer option 2 as exception handling is a bit more tricky in option
> 1 and the purpose of the interceptor is clear.
> >
> > Thanks
> > Oli
> >
> >
> > ________________________________________
> > From: Andrei Shakirin [ashakirin@talend.com]
> > Sent: 09 February 2014 18:19
> > To: dev@cxf.apache.org
> > Subject: RE: REST security enhancements
> >
> > Hi Sergei,
> >
> >> -----Original Message-----
> >> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >> Sent: Donnerstag, 6. Februar 2014 16:55
> >> To: dev@cxf.apache.org
> >> Subject: Re: REST security enhancements
> >>
> >> Hi Oli
> >> On 06/02/14 14:38, Oliver Wulff wrote:
> >>> Hi Sergey
> >>>
> >>> I understand what you mean effort wise but I would also like some
> >>> sort of
> >> features Andrei is asking for. To rewrite or invent a new policy
> >> language is a big step. Maybe we can find something in between like:
> >>>
> >>> Some sort of SecurityInterceptor interface where the implementation
> >>> tells
> >> what kind of credential it is able to handle (similar to the STS
> >> TokenProvider/Validator, etc.) and the DelegationInterceptor
> >> interates through the list to find the interceptor who is capable in
> >> handling the incoming credentials.
> >>>
> >>> Otherwise, it's quite static and not extendible by having something like:
> >>> if (isBasic()) {
> >>> else if (isOAuth()) {
> >>> else if (isSamlP()) {
> >>> else if (isWSFed()) {
> >>> ....
> >>>
> >>> WDYT?
> >>
> >> The interceptors enforcing multiple authentication mechanisms will
> >> come from different modules, and we also have Kerberos, and custom
> >> authorization schemes (example with all sort of OAuth2 tokens);
> >> creating a catch-all security interceptor is possible in principle
> >> but having such an interceptor shipped is not very realistic IMHO.
> >>
> >> By the way, what I meant about the effort: if it can give the real
> >> benefit then it is not a problem spending time implementing it. The
> >> effort I was referring to is about doing a basic interceptor manually
> >> vs configuring some catch-all interceptor and at the moment it is not
> >> obvious to me where this vs. stands in the RS case.
> >>
> >> Are you interested in the automating the way the security
> >> configuration is done, or would like to have a Java-First endpoint
> >> with some basic policy expression which will give a hint to the runtime what
> needs to be done ?
> >>
> >> The latter option might work in principle - we may have different
> >> JAX-RS modules contributing security interceptors check for the
> >> conditions and either ignore or enforce the security as needed.
> >>
> >> This might be worth considering
> >
> > Well, the completely automated configuration IMO is quite difficult to
> > achieve, because normally it is necessary to configure parameters
> > specific for security schema as well (keystores, aliases, callbacks,
> > etc) However from my perspective it could be interesting to change
> > "requirements" and "capabilities" for JAXRS endpoint dynamically. That
> > means that all relevant interceptors are prepared and configured, but
> > decision which from them should go into chain for the current message
> > is made dynamically (based on policy language, configuration, etc )
> >
> > Regards,
> > Andrei.
> >
> >>
> >> Cheers, Sergey
> >>
> >>>
> >>> Thanks
> >>> Oli
> >>>
> >>>
> >>>
> >>> ________________________________________
> >>> From: Sergey Beryozkin [sberyozkin@gmail.com]
> >>> Sent: 06 February 2014 13:23
> >>> To: dev@cxf.apache.org
> >>> Subject: Re: REST security enhancements
> >>>
> >>> Hi Andrei
> >>> On 06/02/14 09:06, Andrei Shakirin wrote:
> >>>> Hi Sergei,
> >>>>
> >>>> For me is also interesting to have a simple way to configure REST
> >>>> service
> >> with authentication schemas it accepts.
> >>>> For example one service will accept only SAML, second service
> >>>> accepts
> >> either Basic Auths or SAML, depending what client sent.
> >>>> For SOAP services that is quite easy to do using WS-Policy assertions.
> >>>> Do you think kind of similar mechanism is useful for REST?
> >>>>
> >>> Right, awhile back I was keen to get a simple policy language
> >>> introduced so that, for example, WADL can contain simple extensions
> >>> like <BasicAuth/>, etc
> >>>
> >>> Now, moving into the the alternatives for a single endpoint
> >>> complicates things a bit, with ExactlyOnce, etc,
> >>>
> >>> The question, does it make sense to mimic a WS-Policy language, and
> >>> if yes, how far shall we go.
> >>>
> >>> Another question is how likely can we get some interoperability
> >>> here, which is what I referred to earlier, with WS all WS-Policy
> >>> aware clients, non-CXF including, will manage it, based on the fact
> >>> (mostly) that WSDL is one of the key pieces enabling the communication.
> >>>
> >>> This is why I'm a bit hesitant right now of having to invest much
> >>> into it; for example, the cost of supporting a number of
> >>> authentication alternatives per a given RS endpoint via the
> >>> policy-like language can be bigger than hacking a delegating
> >>> interceptor - the problem with the manual approach is of course is
> >>> that it can not be properly supported at the tooling/modeling level,
> >>> etc, but on the plus side - well it just works :-).
> >>>
> >>> That said, I think it makes sense to investigate what simple
> >>> language we can come up with for describing simple RS (security)
> >>> policies, example, a single statement, simple alternatives without
> >>> the extra configuration for a start, etc...
> >>>
> >>> Thanks, Sergey
> >>>
> >>>> Regards,
> >>>> Andrei.
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >>>>> Sent: Mittwoch, 5. Februar 2014 22:22
> >>>>> To: dev@cxf.apache.org
> >>>>> Subject: Re: REST security enhancements
> >>>>>
> >>>>> Hi Oli
> >>>>> On 05/02/14 19:56, Oliver Wulff wrote:
> >>>>>> Hi there
> >>>>>>
> >>>>>> For the REST services of the Fediz IDP I'd like to support
> >>>>>> initially three security
> >>>>> use cases.
> >>>>>>
> >>>>>> 1) Basic Authentication, Username/Password validated against the
> >>>>>> STS
> >>>>>> 2) Basic Authentication, Username/Password validated with JAAS
> >>>>> I guess realistically, in case of Basic, it is either 1 or 2
> >>>>>
> >>>>>> 3) SAML token in Basic Authorization header
> >>>>>>
> >>>>>> In CXF 3.0, each REST security interceptor enforces the security
> >>>>>> credentials it
> >>>>> supports. Therefore, you can't just configure all interceptors like:
> >>>>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
> >>>>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
> >>>>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
> >>>>>>
> >>>>>> The interceptors should not throw an exception but instead assert
> >>>>>> the token
> >>>>> (similar the policy) and finally an interceptor checks whether one
> >>>>> token was provided and successfully validated.
> >>>>>>
> >>>>>> Other ideas?
> >>>>>>
> >>>>> I'll be OK with the individual interceptors enforcing it.
> >>>>> Otherwise we'd need to chain them, etc, but having a basic
> >>>>> delegating interceptor which would check the authorization scheme
> >>>>> and do something
> >> like:
> >>>>>
> >>>>> public void handleMessage(Message message) { if
> >>>>> (isBasic(message.get(Message.REQUEST_HEADERS))) {
> >>>>> basicAuthInterceptor.handleMessage(message);
> >>>>> } else {
> >>>>> samlInterceptor.handleMessage(message);
> >>>>> }
> >>>>>
> >>>>> Some basic policy support can be thought of as well, as you said,
> >>>>> for example, we can have a BasicAuthJaas policy - this will use
> >>>>> JAAS interceptor, etc. I think the policies are more interesting
> >>>>> when we can expect some interoperability but also when a series of
> >>>>> interceptors is
> >> needed to validate a single requirement...
> >>>>>
> >>>>> So I'd start with the direct coding first Cheers, Sergey
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Thanks
> >>>>>> Oli
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------
> >>>>>>
> >>>>>> Oliver Wulff
> >>>>>>
> >>>>>> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
> >>>>>> Solution Architect
> >>>>>> http://coders.talend.com
> >>>>>>
> >>>>>> <http://coders.talend.com>Talend Application Integration Division
> >>>>>> http://www.talend.com
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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: REST security enhancements
Posted by Andrei Shakirin <as...@talend.com>.
Hi Sergei,
Yes, I think that is useful and pragmatic substitution for ws-policy.
If user like to limit the service for some authentication schemes only, it is possible to configure corresponded authenticationHandlers (for example Bearer, SAML, Basic or Digest).
Basically very similar mechanism as ws-policy based PolicyInterceptorProvider in jax-ws.
+1 from my side.
Regards,
Andrei.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Freitag, 21. Februar 2014 13:40
> To: dev@cxf.apache.org
> Subject: Re: REST security enhancements
>
> Hi
>
> How about this for a start:
>
> http://git-wip-
> us.apache.org/repos/asf/cxf/blob/55a4b7bf/core/src/main/java/org/apache/cx
> f/interceptor/security/DelegatingAuthenticationInterceptor.java
>
> ?
>
> all this interceptor does is it delegates to the authentication scheme specific
> handler
>
> Thanks, Sergey
>
>
> On 19/02/14 12:29, Oliver Wulff wrote:
> > Hi Sergey, Andrei
> >
> >>>>
> > However from my perspective it could be interesting to change
> > "requirements" and "capabilities" for JAXRS endpoint dynamically. That
> > means that all relevant interceptors are prepared and configured, but
> > decision which from them should go into chain for the current message
> > is made dynamically (based on policy language, configuration, etc )
> >>>>
> >
> > I agree that a REST service provider can configure the interceptors with all
> required configurations like keystores etc. Then I see two options:
> > 1) All security interceptors are in the chain which means they don't fail in
> case of one security interceptor fails and a final interceptor will enforce
> security or not based on some configuration.
> > 2) A single interceptor which dynamically check which interceptor is able to
> handle the current request (canHandleToken/canHandleRequest or
> policyexpression). This requires an interface for the security interceptor to
> know which interceptor can handle a request or which security standard is
> supported by an interceptor.
> >
> > IMHO, I'd prefer option 2 as exception handling is a bit more tricky in option
> 1 and the purpose of the interceptor is clear.
> >
> > Thanks
> > Oli
> >
> >
> > ________________________________________
> > From: Andrei Shakirin [ashakirin@talend.com]
> > Sent: 09 February 2014 18:19
> > To: dev@cxf.apache.org
> > Subject: RE: REST security enhancements
> >
> > Hi Sergei,
> >
> >> -----Original Message-----
> >> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >> Sent: Donnerstag, 6. Februar 2014 16:55
> >> To: dev@cxf.apache.org
> >> Subject: Re: REST security enhancements
> >>
> >> Hi Oli
> >> On 06/02/14 14:38, Oliver Wulff wrote:
> >>> Hi Sergey
> >>>
> >>> I understand what you mean effort wise but I would also like some
> >>> sort of
> >> features Andrei is asking for. To rewrite or invent a new policy
> >> language is a big step. Maybe we can find something in between like:
> >>>
> >>> Some sort of SecurityInterceptor interface where the implementation
> >>> tells
> >> what kind of credential it is able to handle (similar to the STS
> >> TokenProvider/Validator, etc.) and the DelegationInterceptor
> >> interates through the list to find the interceptor who is capable in
> >> handling the incoming credentials.
> >>>
> >>> Otherwise, it's quite static and not extendible by having something like:
> >>> if (isBasic()) {
> >>> else if (isOAuth()) {
> >>> else if (isSamlP()) {
> >>> else if (isWSFed()) {
> >>> ....
> >>>
> >>> WDYT?
> >>
> >> The interceptors enforcing multiple authentication mechanisms will
> >> come from different modules, and we also have Kerberos, and custom
> >> authorization schemes (example with all sort of OAuth2 tokens);
> >> creating a catch-all security interceptor is possible in principle
> >> but having such an interceptor shipped is not very realistic IMHO.
> >>
> >> By the way, what I meant about the effort: if it can give the real
> >> benefit then it is not a problem spending time implementing it. The
> >> effort I was referring to is about doing a basic interceptor manually
> >> vs configuring some catch-all interceptor and at the moment it is not
> >> obvious to me where this vs. stands in the RS case.
> >>
> >> Are you interested in the automating the way the security
> >> configuration is done, or would like to have a Java-First endpoint
> >> with some basic policy expression which will give a hint to the runtime what
> needs to be done ?
> >>
> >> The latter option might work in principle - we may have different
> >> JAX-RS modules contributing security interceptors check for the
> >> conditions and either ignore or enforce the security as needed.
> >>
> >> This might be worth considering
> >
> > Well, the completely automated configuration IMO is quite difficult to
> > achieve, because normally it is necessary to configure parameters
> > specific for security schema as well (keystores, aliases, callbacks,
> > etc) However from my perspective it could be interesting to change
> > "requirements" and "capabilities" for JAXRS endpoint dynamically. That
> > means that all relevant interceptors are prepared and configured, but
> > decision which from them should go into chain for the current message
> > is made dynamically (based on policy language, configuration, etc )
> >
> > Regards,
> > Andrei.
> >
> >>
> >> Cheers, Sergey
> >>
> >>>
> >>> Thanks
> >>> Oli
> >>>
> >>>
> >>>
> >>> ________________________________________
> >>> From: Sergey Beryozkin [sberyozkin@gmail.com]
> >>> Sent: 06 February 2014 13:23
> >>> To: dev@cxf.apache.org
> >>> Subject: Re: REST security enhancements
> >>>
> >>> Hi Andrei
> >>> On 06/02/14 09:06, Andrei Shakirin wrote:
> >>>> Hi Sergei,
> >>>>
> >>>> For me is also interesting to have a simple way to configure REST
> >>>> service
> >> with authentication schemas it accepts.
> >>>> For example one service will accept only SAML, second service
> >>>> accepts
> >> either Basic Auths or SAML, depending what client sent.
> >>>> For SOAP services that is quite easy to do using WS-Policy assertions.
> >>>> Do you think kind of similar mechanism is useful for REST?
> >>>>
> >>> Right, awhile back I was keen to get a simple policy language
> >>> introduced so that, for example, WADL can contain simple extensions
> >>> like <BasicAuth/>, etc
> >>>
> >>> Now, moving into the the alternatives for a single endpoint
> >>> complicates things a bit, with ExactlyOnce, etc,
> >>>
> >>> The question, does it make sense to mimic a WS-Policy language, and
> >>> if yes, how far shall we go.
> >>>
> >>> Another question is how likely can we get some interoperability
> >>> here, which is what I referred to earlier, with WS all WS-Policy
> >>> aware clients, non-CXF including, will manage it, based on the fact
> >>> (mostly) that WSDL is one of the key pieces enabling the communication.
> >>>
> >>> This is why I'm a bit hesitant right now of having to invest much
> >>> into it; for example, the cost of supporting a number of
> >>> authentication alternatives per a given RS endpoint via the
> >>> policy-like language can be bigger than hacking a delegating
> >>> interceptor - the problem with the manual approach is of course is
> >>> that it can not be properly supported at the tooling/modeling level,
> >>> etc, but on the plus side - well it just works :-).
> >>>
> >>> That said, I think it makes sense to investigate what simple
> >>> language we can come up with for describing simple RS (security)
> >>> policies, example, a single statement, simple alternatives without
> >>> the extra configuration for a start, etc...
> >>>
> >>> Thanks, Sergey
> >>>
> >>>> Regards,
> >>>> Andrei.
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >>>>> Sent: Mittwoch, 5. Februar 2014 22:22
> >>>>> To: dev@cxf.apache.org
> >>>>> Subject: Re: REST security enhancements
> >>>>>
> >>>>> Hi Oli
> >>>>> On 05/02/14 19:56, Oliver Wulff wrote:
> >>>>>> Hi there
> >>>>>>
> >>>>>> For the REST services of the Fediz IDP I'd like to support
> >>>>>> initially three security
> >>>>> use cases.
> >>>>>>
> >>>>>> 1) Basic Authentication, Username/Password validated against the
> >>>>>> STS
> >>>>>> 2) Basic Authentication, Username/Password validated with JAAS
> >>>>> I guess realistically, in case of Basic, it is either 1 or 2
> >>>>>
> >>>>>> 3) SAML token in Basic Authorization header
> >>>>>>
> >>>>>> In CXF 3.0, each REST security interceptor enforces the security
> >>>>>> credentials it
> >>>>> supports. Therefore, you can't just configure all interceptors like:
> >>>>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
> >>>>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
> >>>>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
> >>>>>>
> >>>>>> The interceptors should not throw an exception but instead assert
> >>>>>> the token
> >>>>> (similar the policy) and finally an interceptor checks whether one
> >>>>> token was provided and successfully validated.
> >>>>>>
> >>>>>> Other ideas?
> >>>>>>
> >>>>> I'll be OK with the individual interceptors enforcing it.
> >>>>> Otherwise we'd need to chain them, etc, but having a basic
> >>>>> delegating interceptor which would check the authorization scheme
> >>>>> and do something
> >> like:
> >>>>>
> >>>>> public void handleMessage(Message message) { if
> >>>>> (isBasic(message.get(Message.REQUEST_HEADERS))) {
> >>>>> basicAuthInterceptor.handleMessage(message);
> >>>>> } else {
> >>>>> samlInterceptor.handleMessage(message);
> >>>>> }
> >>>>>
> >>>>> Some basic policy support can be thought of as well, as you said,
> >>>>> for example, we can have a BasicAuthJaas policy - this will use
> >>>>> JAAS interceptor, etc. I think the policies are more interesting
> >>>>> when we can expect some interoperability but also when a series of
> >>>>> interceptors is
> >> needed to validate a single requirement...
> >>>>>
> >>>>> So I'd start with the direct coding first Cheers, Sergey
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Thanks
> >>>>>> Oli
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ------
> >>>>>>
> >>>>>> Oliver Wulff
> >>>>>>
> >>>>>> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
> >>>>>> Solution Architect
> >>>>>> http://coders.talend.com
> >>>>>>
> >>>>>> <http://coders.talend.com>Talend Application Integration Division
> >>>>>> http://www.talend.com
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> 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: REST security enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
How about this for a start:
http://git-wip-us.apache.org/repos/asf/cxf/blob/55a4b7bf/core/src/main/java/org/apache/cxf/interceptor/security/DelegatingAuthenticationInterceptor.java
?
all this interceptor does is it delegates to the authentication scheme
specific handler
Thanks, Sergey
On 19/02/14 12:29, Oliver Wulff wrote:
> Hi Sergey, Andrei
>
>>>>
> However from my perspective it could be interesting to change "requirements" and "capabilities" for JAXRS endpoint dynamically. That means that all relevant interceptors are prepared and configured, but decision which from them should go into chain for the current message is made dynamically (based on policy language, configuration, etc )
>>>>
>
> I agree that a REST service provider can configure the interceptors with all required configurations like keystores etc. Then I see two options:
> 1) All security interceptors are in the chain which means they don't fail in case of one security interceptor fails and a final interceptor will enforce security or not based on some configuration.
> 2) A single interceptor which dynamically check which interceptor is able to handle the current request (canHandleToken/canHandleRequest or policyexpression). This requires an interface for the security interceptor to know which interceptor can handle a request or which security standard is supported by an interceptor.
>
> IMHO, I'd prefer option 2 as exception handling is a bit more tricky in option 1 and the purpose of the interceptor is clear.
>
> Thanks
> Oli
>
>
> ________________________________________
> From: Andrei Shakirin [ashakirin@talend.com]
> Sent: 09 February 2014 18:19
> To: dev@cxf.apache.org
> Subject: RE: REST security enhancements
>
> Hi Sergei,
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Donnerstag, 6. Februar 2014 16:55
>> To: dev@cxf.apache.org
>> Subject: Re: REST security enhancements
>>
>> Hi Oli
>> On 06/02/14 14:38, Oliver Wulff wrote:
>>> Hi Sergey
>>>
>>> I understand what you mean effort wise but I would also like some sort of
>> features Andrei is asking for. To rewrite or invent a new policy language is a
>> big step. Maybe we can find something in between like:
>>>
>>> Some sort of SecurityInterceptor interface where the implementation tells
>> what kind of credential it is able to handle (similar to the STS
>> TokenProvider/Validator, etc.) and the DelegationInterceptor interates through
>> the list to find the interceptor who is capable in handling the incoming
>> credentials.
>>>
>>> Otherwise, it's quite static and not extendible by having something like:
>>> if (isBasic()) {
>>> else if (isOAuth()) {
>>> else if (isSamlP()) {
>>> else if (isWSFed()) {
>>> ....
>>>
>>> WDYT?
>>
>> The interceptors enforcing multiple authentication mechanisms will come from
>> different modules, and we also have Kerberos, and custom authorization
>> schemes (example with all sort of OAuth2 tokens); creating a catch-all security
>> interceptor is possible in principle but having such an interceptor shipped is not
>> very realistic IMHO.
>>
>> By the way, what I meant about the effort: if it can give the real benefit then it
>> is not a problem spending time implementing it. The effort I was referring to is
>> about doing a basic interceptor manually vs configuring some catch-all
>> interceptor and at the moment it is not obvious to me where this vs. stands in
>> the RS case.
>>
>> Are you interested in the automating the way the security configuration is
>> done, or would like to have a Java-First endpoint with some basic policy
>> expression which will give a hint to the runtime what needs to be done ?
>>
>> The latter option might work in principle - we may have different JAX-RS
>> modules contributing security interceptors check for the conditions and either
>> ignore or enforce the security as needed.
>>
>> This might be worth considering
>
> Well, the completely automated configuration IMO is quite difficult to achieve, because normally it is necessary to configure parameters specific for security schema as well (keystores, aliases, callbacks, etc)
> However from my perspective it could be interesting to change "requirements" and "capabilities" for JAXRS endpoint dynamically. That means that all relevant interceptors are prepared and configured, but decision which from them should go into chain for the current message is made dynamically (based on policy language, configuration, etc )
>
> Regards,
> Andrei.
>
>>
>> Cheers, Sergey
>>
>>>
>>> Thanks
>>> Oli
>>>
>>>
>>>
>>> ________________________________________
>>> From: Sergey Beryozkin [sberyozkin@gmail.com]
>>> Sent: 06 February 2014 13:23
>>> To: dev@cxf.apache.org
>>> Subject: Re: REST security enhancements
>>>
>>> Hi Andrei
>>> On 06/02/14 09:06, Andrei Shakirin wrote:
>>>> Hi Sergei,
>>>>
>>>> For me is also interesting to have a simple way to configure REST service
>> with authentication schemas it accepts.
>>>> For example one service will accept only SAML, second service accepts
>> either Basic Auths or SAML, depending what client sent.
>>>> For SOAP services that is quite easy to do using WS-Policy assertions.
>>>> Do you think kind of similar mechanism is useful for REST?
>>>>
>>> Right, awhile back I was keen to get a simple policy language
>>> introduced so that, for example, WADL can contain simple extensions
>>> like <BasicAuth/>, etc
>>>
>>> Now, moving into the the alternatives for a single endpoint
>>> complicates things a bit, with ExactlyOnce, etc,
>>>
>>> The question, does it make sense to mimic a WS-Policy language, and if
>>> yes, how far shall we go.
>>>
>>> Another question is how likely can we get some interoperability here,
>>> which is what I referred to earlier, with WS all WS-Policy aware
>>> clients, non-CXF including, will manage it, based on the fact (mostly)
>>> that WSDL is one of the key pieces enabling the communication.
>>>
>>> This is why I'm a bit hesitant right now of having to invest much into
>>> it; for example, the cost of supporting a number of authentication
>>> alternatives per a given RS endpoint via the policy-like language can
>>> be bigger than hacking a delegating interceptor - the problem with the
>>> manual approach is of course is that it can not be properly supported
>>> at the tooling/modeling level, etc, but on the plus side - well it
>>> just works :-).
>>>
>>> That said, I think it makes sense to investigate what simple language
>>> we can come up with for describing simple RS (security) policies,
>>> example, a single statement, simple alternatives without the extra
>>> configuration for a start, etc...
>>>
>>> Thanks, Sergey
>>>
>>>> Regards,
>>>> Andrei.
>>>>
>>>>> -----Original Message-----
>>>>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>>>>> Sent: Mittwoch, 5. Februar 2014 22:22
>>>>> To: dev@cxf.apache.org
>>>>> Subject: Re: REST security enhancements
>>>>>
>>>>> Hi Oli
>>>>> On 05/02/14 19:56, Oliver Wulff wrote:
>>>>>> Hi there
>>>>>>
>>>>>> For the REST services of the Fediz IDP I'd like to support
>>>>>> initially three security
>>>>> use cases.
>>>>>>
>>>>>> 1) Basic Authentication, Username/Password validated against the
>>>>>> STS
>>>>>> 2) Basic Authentication, Username/Password validated with JAAS
>>>>> I guess realistically, in case of Basic, it is either 1 or 2
>>>>>
>>>>>> 3) SAML token in Basic Authorization header
>>>>>>
>>>>>> In CXF 3.0, each REST security interceptor enforces the security
>>>>>> credentials it
>>>>> supports. Therefore, you can't just configure all interceptors like:
>>>>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
>>>>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
>>>>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
>>>>>>
>>>>>> The interceptors should not throw an exception but instead assert
>>>>>> the token
>>>>> (similar the policy) and finally an interceptor checks whether one
>>>>> token was provided and successfully validated.
>>>>>>
>>>>>> Other ideas?
>>>>>>
>>>>> I'll be OK with the individual interceptors enforcing it. Otherwise
>>>>> we'd need to chain them, etc, but having a basic delegating
>>>>> interceptor which would check the authorization scheme and do something
>> like:
>>>>>
>>>>> public void handleMessage(Message message) { if
>>>>> (isBasic(message.get(Message.REQUEST_HEADERS))) {
>>>>> basicAuthInterceptor.handleMessage(message);
>>>>> } else {
>>>>> samlInterceptor.handleMessage(message);
>>>>> }
>>>>>
>>>>> Some basic policy support can be thought of as well, as you said,
>>>>> for example, we can have a BasicAuthJaas policy - this will use JAAS
>>>>> interceptor, etc. I think the policies are more interesting when we
>>>>> can expect some interoperability but also when a series of interceptors is
>> needed to validate a single requirement...
>>>>>
>>>>> So I'd start with the direct coding first Cheers, Sergey
>>>>>
>>>>>
>>>>>
>>>>>> Thanks
>>>>>> Oli
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------
>>>>>>
>>>>>> Oliver Wulff
>>>>>>
>>>>>> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
>>>>>> Solution Architect
>>>>>> http://coders.talend.com
>>>>>>
>>>>>> <http://coders.talend.com>Talend Application Integration Division
>>>>>> http://www.talend.com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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: REST security enhancements
Posted by Oliver Wulff <ow...@talend.com>.
Hi Sergey, Andrei
>>>
However from my perspective it could be interesting to change "requirements" and "capabilities" for JAXRS endpoint dynamically. That means that all relevant interceptors are prepared and configured, but decision which from them should go into chain for the current message is made dynamically (based on policy language, configuration, etc )
>>>
I agree that a REST service provider can configure the interceptors with all required configurations like keystores etc. Then I see two options:
1) All security interceptors are in the chain which means they don't fail in case of one security interceptor fails and a final interceptor will enforce security or not based on some configuration.
2) A single interceptor which dynamically check which interceptor is able to handle the current request (canHandleToken/canHandleRequest or policyexpression). This requires an interface for the security interceptor to know which interceptor can handle a request or which security standard is supported by an interceptor.
IMHO, I'd prefer option 2 as exception handling is a bit more tricky in option 1 and the purpose of the interceptor is clear.
Thanks
Oli
________________________________________
From: Andrei Shakirin [ashakirin@talend.com]
Sent: 09 February 2014 18:19
To: dev@cxf.apache.org
Subject: RE: REST security enhancements
Hi Sergei,
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Donnerstag, 6. Februar 2014 16:55
> To: dev@cxf.apache.org
> Subject: Re: REST security enhancements
>
> Hi Oli
> On 06/02/14 14:38, Oliver Wulff wrote:
> > Hi Sergey
> >
> > I understand what you mean effort wise but I would also like some sort of
> features Andrei is asking for. To rewrite or invent a new policy language is a
> big step. Maybe we can find something in between like:
> >
> > Some sort of SecurityInterceptor interface where the implementation tells
> what kind of credential it is able to handle (similar to the STS
> TokenProvider/Validator, etc.) and the DelegationInterceptor interates through
> the list to find the interceptor who is capable in handling the incoming
> credentials.
> >
> > Otherwise, it's quite static and not extendible by having something like:
> > if (isBasic()) {
> > else if (isOAuth()) {
> > else if (isSamlP()) {
> > else if (isWSFed()) {
> > ....
> >
> > WDYT?
>
> The interceptors enforcing multiple authentication mechanisms will come from
> different modules, and we also have Kerberos, and custom authorization
> schemes (example with all sort of OAuth2 tokens); creating a catch-all security
> interceptor is possible in principle but having such an interceptor shipped is not
> very realistic IMHO.
>
> By the way, what I meant about the effort: if it can give the real benefit then it
> is not a problem spending time implementing it. The effort I was referring to is
> about doing a basic interceptor manually vs configuring some catch-all
> interceptor and at the moment it is not obvious to me where this vs. stands in
> the RS case.
>
> Are you interested in the automating the way the security configuration is
> done, or would like to have a Java-First endpoint with some basic policy
> expression which will give a hint to the runtime what needs to be done ?
>
> The latter option might work in principle - we may have different JAX-RS
> modules contributing security interceptors check for the conditions and either
> ignore or enforce the security as needed.
>
> This might be worth considering
Well, the completely automated configuration IMO is quite difficult to achieve, because normally it is necessary to configure parameters specific for security schema as well (keystores, aliases, callbacks, etc)
However from my perspective it could be interesting to change "requirements" and "capabilities" for JAXRS endpoint dynamically. That means that all relevant interceptors are prepared and configured, but decision which from them should go into chain for the current message is made dynamically (based on policy language, configuration, etc )
Regards,
Andrei.
>
> Cheers, Sergey
>
> >
> > Thanks
> > Oli
> >
> >
> >
> > ________________________________________
> > From: Sergey Beryozkin [sberyozkin@gmail.com]
> > Sent: 06 February 2014 13:23
> > To: dev@cxf.apache.org
> > Subject: Re: REST security enhancements
> >
> > Hi Andrei
> > On 06/02/14 09:06, Andrei Shakirin wrote:
> >> Hi Sergei,
> >>
> >> For me is also interesting to have a simple way to configure REST service
> with authentication schemas it accepts.
> >> For example one service will accept only SAML, second service accepts
> either Basic Auths or SAML, depending what client sent.
> >> For SOAP services that is quite easy to do using WS-Policy assertions.
> >> Do you think kind of similar mechanism is useful for REST?
> >>
> > Right, awhile back I was keen to get a simple policy language
> > introduced so that, for example, WADL can contain simple extensions
> > like <BasicAuth/>, etc
> >
> > Now, moving into the the alternatives for a single endpoint
> > complicates things a bit, with ExactlyOnce, etc,
> >
> > The question, does it make sense to mimic a WS-Policy language, and if
> > yes, how far shall we go.
> >
> > Another question is how likely can we get some interoperability here,
> > which is what I referred to earlier, with WS all WS-Policy aware
> > clients, non-CXF including, will manage it, based on the fact (mostly)
> > that WSDL is one of the key pieces enabling the communication.
> >
> > This is why I'm a bit hesitant right now of having to invest much into
> > it; for example, the cost of supporting a number of authentication
> > alternatives per a given RS endpoint via the policy-like language can
> > be bigger than hacking a delegating interceptor - the problem with the
> > manual approach is of course is that it can not be properly supported
> > at the tooling/modeling level, etc, but on the plus side - well it
> > just works :-).
> >
> > That said, I think it makes sense to investigate what simple language
> > we can come up with for describing simple RS (security) policies,
> > example, a single statement, simple alternatives without the extra
> > configuration for a start, etc...
> >
> > Thanks, Sergey
> >
> >> Regards,
> >> Andrei.
> >>
> >>> -----Original Message-----
> >>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >>> Sent: Mittwoch, 5. Februar 2014 22:22
> >>> To: dev@cxf.apache.org
> >>> Subject: Re: REST security enhancements
> >>>
> >>> Hi Oli
> >>> On 05/02/14 19:56, Oliver Wulff wrote:
> >>>> Hi there
> >>>>
> >>>> For the REST services of the Fediz IDP I'd like to support
> >>>> initially three security
> >>> use cases.
> >>>>
> >>>> 1) Basic Authentication, Username/Password validated against the
> >>>> STS
> >>>> 2) Basic Authentication, Username/Password validated with JAAS
> >>> I guess realistically, in case of Basic, it is either 1 or 2
> >>>
> >>>> 3) SAML token in Basic Authorization header
> >>>>
> >>>> In CXF 3.0, each REST security interceptor enforces the security
> >>>> credentials it
> >>> supports. Therefore, you can't just configure all interceptors like:
> >>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
> >>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
> >>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
> >>>>
> >>>> The interceptors should not throw an exception but instead assert
> >>>> the token
> >>> (similar the policy) and finally an interceptor checks whether one
> >>> token was provided and successfully validated.
> >>>>
> >>>> Other ideas?
> >>>>
> >>> I'll be OK with the individual interceptors enforcing it. Otherwise
> >>> we'd need to chain them, etc, but having a basic delegating
> >>> interceptor which would check the authorization scheme and do something
> like:
> >>>
> >>> public void handleMessage(Message message) { if
> >>> (isBasic(message.get(Message.REQUEST_HEADERS))) {
> >>> basicAuthInterceptor.handleMessage(message);
> >>> } else {
> >>> samlInterceptor.handleMessage(message);
> >>> }
> >>>
> >>> Some basic policy support can be thought of as well, as you said,
> >>> for example, we can have a BasicAuthJaas policy - this will use JAAS
> >>> interceptor, etc. I think the policies are more interesting when we
> >>> can expect some interoperability but also when a series of interceptors is
> needed to validate a single requirement...
> >>>
> >>> So I'd start with the direct coding first Cheers, Sergey
> >>>
> >>>
> >>>
> >>>> Thanks
> >>>> Oli
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ------
> >>>>
> >>>> Oliver Wulff
> >>>>
> >>>> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
> >>>> Solution Architect
> >>>> http://coders.talend.com
> >>>>
> >>>> <http://coders.talend.com>Talend Application Integration Division
> >>>> http://www.talend.com
> >>>>
> >>>
> >>>
> >>> --
> >>> 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: REST security enhancements
Posted by Andrei Shakirin <as...@talend.com>.
Hi Sergei,
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Donnerstag, 6. Februar 2014 16:55
> To: dev@cxf.apache.org
> Subject: Re: REST security enhancements
>
> Hi Oli
> On 06/02/14 14:38, Oliver Wulff wrote:
> > Hi Sergey
> >
> > I understand what you mean effort wise but I would also like some sort of
> features Andrei is asking for. To rewrite or invent a new policy language is a
> big step. Maybe we can find something in between like:
> >
> > Some sort of SecurityInterceptor interface where the implementation tells
> what kind of credential it is able to handle (similar to the STS
> TokenProvider/Validator, etc.) and the DelegationInterceptor interates through
> the list to find the interceptor who is capable in handling the incoming
> credentials.
> >
> > Otherwise, it's quite static and not extendible by having something like:
> > if (isBasic()) {
> > else if (isOAuth()) {
> > else if (isSamlP()) {
> > else if (isWSFed()) {
> > ....
> >
> > WDYT?
>
> The interceptors enforcing multiple authentication mechanisms will come from
> different modules, and we also have Kerberos, and custom authorization
> schemes (example with all sort of OAuth2 tokens); creating a catch-all security
> interceptor is possible in principle but having such an interceptor shipped is not
> very realistic IMHO.
>
> By the way, what I meant about the effort: if it can give the real benefit then it
> is not a problem spending time implementing it. The effort I was referring to is
> about doing a basic interceptor manually vs configuring some catch-all
> interceptor and at the moment it is not obvious to me where this vs. stands in
> the RS case.
>
> Are you interested in the automating the way the security configuration is
> done, or would like to have a Java-First endpoint with some basic policy
> expression which will give a hint to the runtime what needs to be done ?
>
> The latter option might work in principle - we may have different JAX-RS
> modules contributing security interceptors check for the conditions and either
> ignore or enforce the security as needed.
>
> This might be worth considering
Well, the completely automated configuration IMO is quite difficult to achieve, because normally it is necessary to configure parameters specific for security schema as well (keystores, aliases, callbacks, etc)
However from my perspective it could be interesting to change "requirements" and "capabilities" for JAXRS endpoint dynamically. That means that all relevant interceptors are prepared and configured, but decision which from them should go into chain for the current message is made dynamically (based on policy language, configuration, etc )
Regards,
Andrei.
>
> Cheers, Sergey
>
> >
> > Thanks
> > Oli
> >
> >
> >
> > ________________________________________
> > From: Sergey Beryozkin [sberyozkin@gmail.com]
> > Sent: 06 February 2014 13:23
> > To: dev@cxf.apache.org
> > Subject: Re: REST security enhancements
> >
> > Hi Andrei
> > On 06/02/14 09:06, Andrei Shakirin wrote:
> >> Hi Sergei,
> >>
> >> For me is also interesting to have a simple way to configure REST service
> with authentication schemas it accepts.
> >> For example one service will accept only SAML, second service accepts
> either Basic Auths or SAML, depending what client sent.
> >> For SOAP services that is quite easy to do using WS-Policy assertions.
> >> Do you think kind of similar mechanism is useful for REST?
> >>
> > Right, awhile back I was keen to get a simple policy language
> > introduced so that, for example, WADL can contain simple extensions
> > like <BasicAuth/>, etc
> >
> > Now, moving into the the alternatives for a single endpoint
> > complicates things a bit, with ExactlyOnce, etc,
> >
> > The question, does it make sense to mimic a WS-Policy language, and if
> > yes, how far shall we go.
> >
> > Another question is how likely can we get some interoperability here,
> > which is what I referred to earlier, with WS all WS-Policy aware
> > clients, non-CXF including, will manage it, based on the fact (mostly)
> > that WSDL is one of the key pieces enabling the communication.
> >
> > This is why I'm a bit hesitant right now of having to invest much into
> > it; for example, the cost of supporting a number of authentication
> > alternatives per a given RS endpoint via the policy-like language can
> > be bigger than hacking a delegating interceptor - the problem with the
> > manual approach is of course is that it can not be properly supported
> > at the tooling/modeling level, etc, but on the plus side - well it
> > just works :-).
> >
> > That said, I think it makes sense to investigate what simple language
> > we can come up with for describing simple RS (security) policies,
> > example, a single statement, simple alternatives without the extra
> > configuration for a start, etc...
> >
> > Thanks, Sergey
> >
> >> Regards,
> >> Andrei.
> >>
> >>> -----Original Message-----
> >>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >>> Sent: Mittwoch, 5. Februar 2014 22:22
> >>> To: dev@cxf.apache.org
> >>> Subject: Re: REST security enhancements
> >>>
> >>> Hi Oli
> >>> On 05/02/14 19:56, Oliver Wulff wrote:
> >>>> Hi there
> >>>>
> >>>> For the REST services of the Fediz IDP I'd like to support
> >>>> initially three security
> >>> use cases.
> >>>>
> >>>> 1) Basic Authentication, Username/Password validated against the
> >>>> STS
> >>>> 2) Basic Authentication, Username/Password validated with JAAS
> >>> I guess realistically, in case of Basic, it is either 1 or 2
> >>>
> >>>> 3) SAML token in Basic Authorization header
> >>>>
> >>>> In CXF 3.0, each REST security interceptor enforces the security
> >>>> credentials it
> >>> supports. Therefore, you can't just configure all interceptors like:
> >>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
> >>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
> >>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
> >>>>
> >>>> The interceptors should not throw an exception but instead assert
> >>>> the token
> >>> (similar the policy) and finally an interceptor checks whether one
> >>> token was provided and successfully validated.
> >>>>
> >>>> Other ideas?
> >>>>
> >>> I'll be OK with the individual interceptors enforcing it. Otherwise
> >>> we'd need to chain them, etc, but having a basic delegating
> >>> interceptor which would check the authorization scheme and do something
> like:
> >>>
> >>> public void handleMessage(Message message) { if
> >>> (isBasic(message.get(Message.REQUEST_HEADERS))) {
> >>> basicAuthInterceptor.handleMessage(message);
> >>> } else {
> >>> samlInterceptor.handleMessage(message);
> >>> }
> >>>
> >>> Some basic policy support can be thought of as well, as you said,
> >>> for example, we can have a BasicAuthJaas policy - this will use JAAS
> >>> interceptor, etc. I think the policies are more interesting when we
> >>> can expect some interoperability but also when a series of interceptors is
> needed to validate a single requirement...
> >>>
> >>> So I'd start with the direct coding first Cheers, Sergey
> >>>
> >>>
> >>>
> >>>> Thanks
> >>>> Oli
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ------
> >>>>
> >>>> Oliver Wulff
> >>>>
> >>>> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
> >>>> Solution Architect
> >>>> http://coders.talend.com
> >>>>
> >>>> <http://coders.talend.com>Talend Application Integration Division
> >>>> http://www.talend.com
> >>>>
> >>>
> >>>
> >>> --
> >>> 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: REST security enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Oli
On 06/02/14 14:38, Oliver Wulff wrote:
> Hi Sergey
>
> I understand what you mean effort wise but I would also like some sort of features Andrei is asking for. To rewrite or invent a new policy language is a big step. Maybe we can find something in between like:
>
> Some sort of SecurityInterceptor interface where the implementation tells what kind of credential it is able to handle (similar to the STS TokenProvider/Validator, etc.) and the DelegationInterceptor interates through the list to find the interceptor who is capable in handling the incoming credentials.
>
> Otherwise, it's quite static and not extendible by having something like:
> if (isBasic()) {
> else if (isOAuth()) {
> else if (isSamlP()) {
> else if (isWSFed()) {
> ....
>
> WDYT?
The interceptors enforcing multiple authentication mechanisms will come
from different modules, and we also have Kerberos, and custom
authorization schemes (example with all sort of OAuth2 tokens); creating
a catch-all security interceptor is possible in principle but having
such an interceptor shipped is not very realistic IMHO.
By the way, what I meant about the effort: if it can give the real
benefit then it is not a problem spending time implementing it. The
effort I was referring to is about doing a basic interceptor manually vs
configuring some catch-all interceptor and at the moment it is not
obvious to me where this vs. stands in the RS case.
Are you interested in the automating the way the security configuration
is done, or would like to have a Java-First endpoint with some basic
policy expression which will give a hint to the runtime what needs to be
done ?
The latter option might work in principle - we may have different JAX-RS
modules contributing security interceptors check for the conditions and
either ignore or enforce the security as needed.
This might be worth considering
Cheers, Sergey
>
> Thanks
> Oli
>
>
>
> ________________________________________
> From: Sergey Beryozkin [sberyozkin@gmail.com]
> Sent: 06 February 2014 13:23
> To: dev@cxf.apache.org
> Subject: Re: REST security enhancements
>
> Hi Andrei
> On 06/02/14 09:06, Andrei Shakirin wrote:
>> Hi Sergei,
>>
>> For me is also interesting to have a simple way to configure REST service with authentication schemas it accepts.
>> For example one service will accept only SAML, second service accepts either Basic Auths or SAML, depending what client sent.
>> For SOAP services that is quite easy to do using WS-Policy assertions.
>> Do you think kind of similar mechanism is useful for REST?
>>
> Right, awhile back I was keen to get a simple policy language introduced
> so that, for example, WADL can contain simple extensions like
> <BasicAuth/>, etc
>
> Now, moving into the the alternatives for a single endpoint complicates
> things a bit, with ExactlyOnce, etc,
>
> The question, does it make sense to mimic a WS-Policy language, and if
> yes, how far shall we go.
>
> Another question is how likely can we get some interoperability here,
> which is what I referred to earlier, with WS all WS-Policy aware
> clients, non-CXF including, will manage it, based on the fact (mostly)
> that WSDL is one of the key pieces enabling the communication.
>
> This is why I'm a bit hesitant right now of having to invest much into
> it; for example, the cost of supporting a number of authentication
> alternatives per a given RS endpoint via the policy-like language can be
> bigger than hacking a delegating interceptor - the problem with the
> manual approach is of course is that it can not be properly supported at
> the tooling/modeling level, etc, but on the plus side - well it just
> works :-).
>
> That said, I think it makes sense to investigate what simple language we
> can come up with for describing simple RS (security) policies, example,
> a single statement, simple alternatives without the extra configuration
> for a start, etc...
>
> Thanks, Sergey
>
>> Regards,
>> Andrei.
>>
>>> -----Original Message-----
>>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>>> Sent: Mittwoch, 5. Februar 2014 22:22
>>> To: dev@cxf.apache.org
>>> Subject: Re: REST security enhancements
>>>
>>> Hi Oli
>>> On 05/02/14 19:56, Oliver Wulff wrote:
>>>> Hi there
>>>>
>>>> For the REST services of the Fediz IDP I'd like to support initially three security
>>> use cases.
>>>>
>>>> 1) Basic Authentication, Username/Password validated against the STS
>>>> 2) Basic Authentication, Username/Password validated with JAAS
>>> I guess realistically, in case of Basic, it is either 1 or 2
>>>
>>>> 3) SAML token in Basic Authorization header
>>>>
>>>> In CXF 3.0, each REST security interceptor enforces the security credentials it
>>> supports. Therefore, you can't just configure all interceptors like:
>>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
>>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
>>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
>>>>
>>>> The interceptors should not throw an exception but instead assert the token
>>> (similar the policy) and finally an interceptor checks whether one token was
>>> provided and successfully validated.
>>>>
>>>> Other ideas?
>>>>
>>> I'll be OK with the individual interceptors enforcing it. Otherwise we'd need to
>>> chain them, etc, but having a basic delegating interceptor which would check
>>> the authorization scheme and do something like:
>>>
>>> public void handleMessage(Message message) { if
>>> (isBasic(message.get(Message.REQUEST_HEADERS))) {
>>> basicAuthInterceptor.handleMessage(message);
>>> } else {
>>> samlInterceptor.handleMessage(message);
>>> }
>>>
>>> Some basic policy support can be thought of as well, as you said, for example,
>>> we can have a BasicAuthJaas policy - this will use JAAS interceptor, etc. I think
>>> the policies are more interesting when we can expect some interoperability but
>>> also when a series of interceptors is needed to validate a single requirement...
>>>
>>> So I'd start with the direct coding first Cheers, Sergey
>>>
>>>
>>>
>>>> Thanks
>>>> Oli
>>>>
>>>>
>>>>
>>>>
>>>> ------
>>>>
>>>> Oliver Wulff
>>>>
>>>> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
>>>> Solution Architect
>>>> http://coders.talend.com
>>>>
>>>> <http://coders.talend.com>Talend Application Integration Division
>>>> http://www.talend.com
>>>>
>>>
>>>
>>> --
>>> 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: REST security enhancements
Posted by Oliver Wulff <ow...@talend.com>.
Hi Sergey
I understand what you mean effort wise but I would also like some sort of features Andrei is asking for. To rewrite or invent a new policy language is a big step. Maybe we can find something in between like:
Some sort of SecurityInterceptor interface where the implementation tells what kind of credential it is able to handle (similar to the STS TokenProvider/Validator, etc.) and the DelegationInterceptor interates through the list to find the interceptor who is capable in handling the incoming credentials.
Otherwise, it's quite static and not extendible by having something like:
if (isBasic()) {
else if (isOAuth()) {
else if (isSamlP()) {
else if (isWSFed()) {
....
WDYT?
Thanks
Oli
________________________________________
From: Sergey Beryozkin [sberyozkin@gmail.com]
Sent: 06 February 2014 13:23
To: dev@cxf.apache.org
Subject: Re: REST security enhancements
Hi Andrei
On 06/02/14 09:06, Andrei Shakirin wrote:
> Hi Sergei,
>
> For me is also interesting to have a simple way to configure REST service with authentication schemas it accepts.
> For example one service will accept only SAML, second service accepts either Basic Auths or SAML, depending what client sent.
> For SOAP services that is quite easy to do using WS-Policy assertions.
> Do you think kind of similar mechanism is useful for REST?
>
Right, awhile back I was keen to get a simple policy language introduced
so that, for example, WADL can contain simple extensions like
<BasicAuth/>, etc
Now, moving into the the alternatives for a single endpoint complicates
things a bit, with ExactlyOnce, etc,
The question, does it make sense to mimic a WS-Policy language, and if
yes, how far shall we go.
Another question is how likely can we get some interoperability here,
which is what I referred to earlier, with WS all WS-Policy aware
clients, non-CXF including, will manage it, based on the fact (mostly)
that WSDL is one of the key pieces enabling the communication.
This is why I'm a bit hesitant right now of having to invest much into
it; for example, the cost of supporting a number of authentication
alternatives per a given RS endpoint via the policy-like language can be
bigger than hacking a delegating interceptor - the problem with the
manual approach is of course is that it can not be properly supported at
the tooling/modeling level, etc, but on the plus side - well it just
works :-).
That said, I think it makes sense to investigate what simple language we
can come up with for describing simple RS (security) policies, example,
a single statement, simple alternatives without the extra configuration
for a start, etc...
Thanks, Sergey
> Regards,
> Andrei.
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Mittwoch, 5. Februar 2014 22:22
>> To: dev@cxf.apache.org
>> Subject: Re: REST security enhancements
>>
>> Hi Oli
>> On 05/02/14 19:56, Oliver Wulff wrote:
>>> Hi there
>>>
>>> For the REST services of the Fediz IDP I'd like to support initially three security
>> use cases.
>>>
>>> 1) Basic Authentication, Username/Password validated against the STS
>>> 2) Basic Authentication, Username/Password validated with JAAS
>> I guess realistically, in case of Basic, it is either 1 or 2
>>
>>> 3) SAML token in Basic Authorization header
>>>
>>> In CXF 3.0, each REST security interceptor enforces the security credentials it
>> supports. Therefore, you can't just configure all interceptors like:
>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
>>>
>>> The interceptors should not throw an exception but instead assert the token
>> (similar the policy) and finally an interceptor checks whether one token was
>> provided and successfully validated.
>>>
>>> Other ideas?
>>>
>> I'll be OK with the individual interceptors enforcing it. Otherwise we'd need to
>> chain them, etc, but having a basic delegating interceptor which would check
>> the authorization scheme and do something like:
>>
>> public void handleMessage(Message message) { if
>> (isBasic(message.get(Message.REQUEST_HEADERS))) {
>> basicAuthInterceptor.handleMessage(message);
>> } else {
>> samlInterceptor.handleMessage(message);
>> }
>>
>> Some basic policy support can be thought of as well, as you said, for example,
>> we can have a BasicAuthJaas policy - this will use JAAS interceptor, etc. I think
>> the policies are more interesting when we can expect some interoperability but
>> also when a series of interceptors is needed to validate a single requirement...
>>
>> So I'd start with the direct coding first Cheers, Sergey
>>
>>
>>
>>> Thanks
>>> Oli
>>>
>>>
>>>
>>>
>>> ------
>>>
>>> Oliver Wulff
>>>
>>> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
>>> Solution Architect
>>> http://coders.talend.com
>>>
>>> <http://coders.talend.com>Talend Application Integration Division
>>> http://www.talend.com
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
Re: REST security enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andrei
On 06/02/14 09:06, Andrei Shakirin wrote:
> Hi Sergei,
>
> For me is also interesting to have a simple way to configure REST service with authentication schemas it accepts.
> For example one service will accept only SAML, second service accepts either Basic Auths or SAML, depending what client sent.
> For SOAP services that is quite easy to do using WS-Policy assertions.
> Do you think kind of similar mechanism is useful for REST?
>
Right, awhile back I was keen to get a simple policy language introduced
so that, for example, WADL can contain simple extensions like
<BasicAuth/>, etc
Now, moving into the the alternatives for a single endpoint complicates
things a bit, with ExactlyOnce, etc,
The question, does it make sense to mimic a WS-Policy language, and if
yes, how far shall we go.
Another question is how likely can we get some interoperability here,
which is what I referred to earlier, with WS all WS-Policy aware
clients, non-CXF including, will manage it, based on the fact (mostly)
that WSDL is one of the key pieces enabling the communication.
This is why I'm a bit hesitant right now of having to invest much into
it; for example, the cost of supporting a number of authentication
alternatives per a given RS endpoint via the policy-like language can be
bigger than hacking a delegating interceptor - the problem with the
manual approach is of course is that it can not be properly supported at
the tooling/modeling level, etc, but on the plus side - well it just
works :-).
That said, I think it makes sense to investigate what simple language we
can come up with for describing simple RS (security) policies, example,
a single statement, simple alternatives without the extra configuration
for a start, etc...
Thanks, Sergey
> Regards,
> Andrei.
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Mittwoch, 5. Februar 2014 22:22
>> To: dev@cxf.apache.org
>> Subject: Re: REST security enhancements
>>
>> Hi Oli
>> On 05/02/14 19:56, Oliver Wulff wrote:
>>> Hi there
>>>
>>> For the REST services of the Fediz IDP I'd like to support initially three security
>> use cases.
>>>
>>> 1) Basic Authentication, Username/Password validated against the STS
>>> 2) Basic Authentication, Username/Password validated with JAAS
>> I guess realistically, in case of Basic, it is either 1 or 2
>>
>>> 3) SAML token in Basic Authorization header
>>>
>>> In CXF 3.0, each REST security interceptor enforces the security credentials it
>> supports. Therefore, you can't just configure all interceptors like:
>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
>>>
>>> The interceptors should not throw an exception but instead assert the token
>> (similar the policy) and finally an interceptor checks whether one token was
>> provided and successfully validated.
>>>
>>> Other ideas?
>>>
>> I'll be OK with the individual interceptors enforcing it. Otherwise we'd need to
>> chain them, etc, but having a basic delegating interceptor which would check
>> the authorization scheme and do something like:
>>
>> public void handleMessage(Message message) { if
>> (isBasic(message.get(Message.REQUEST_HEADERS))) {
>> basicAuthInterceptor.handleMessage(message);
>> } else {
>> samlInterceptor.handleMessage(message);
>> }
>>
>> Some basic policy support can be thought of as well, as you said, for example,
>> we can have a BasicAuthJaas policy - this will use JAAS interceptor, etc. I think
>> the policies are more interesting when we can expect some interoperability but
>> also when a series of interceptors is needed to validate a single requirement...
>>
>> So I'd start with the direct coding first Cheers, Sergey
>>
>>
>>
>>> Thanks
>>> Oli
>>>
>>>
>>>
>>>
>>> ------
>>>
>>> Oliver Wulff
>>>
>>> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
>>> Solution Architect
>>> http://coders.talend.com
>>>
>>> <http://coders.talend.com>Talend Application Integration Division
>>> http://www.talend.com
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
RE: REST security enhancements
Posted by Andrei Shakirin <as...@talend.com>.
Hi Sergei,
For me is also interesting to have a simple way to configure REST service with authentication schemas it accepts.
For example one service will accept only SAML, second service accepts either Basic Auths or SAML, depending what client sent.
For SOAP services that is quite easy to do using WS-Policy assertions.
Do you think kind of similar mechanism is useful for REST?
Regards,
Andrei.
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Mittwoch, 5. Februar 2014 22:22
> To: dev@cxf.apache.org
> Subject: Re: REST security enhancements
>
> Hi Oli
> On 05/02/14 19:56, Oliver Wulff wrote:
> > Hi there
> >
> > For the REST services of the Fediz IDP I'd like to support initially three security
> use cases.
> >
> > 1) Basic Authentication, Username/Password validated against the STS
> > 2) Basic Authentication, Username/Password validated with JAAS
> I guess realistically, in case of Basic, it is either 1 or 2
>
> > 3) SAML token in Basic Authorization header
> >
> > In CXF 3.0, each REST security interceptor enforces the security credentials it
> supports. Therefore, you can't just configure all interceptors like:
> > org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
> > org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
> > org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
> >
> > The interceptors should not throw an exception but instead assert the token
> (similar the policy) and finally an interceptor checks whether one token was
> provided and successfully validated.
> >
> > Other ideas?
> >
> I'll be OK with the individual interceptors enforcing it. Otherwise we'd need to
> chain them, etc, but having a basic delegating interceptor which would check
> the authorization scheme and do something like:
>
> public void handleMessage(Message message) { if
> (isBasic(message.get(Message.REQUEST_HEADERS))) {
> basicAuthInterceptor.handleMessage(message);
> } else {
> samlInterceptor.handleMessage(message);
> }
>
> Some basic policy support can be thought of as well, as you said, for example,
> we can have a BasicAuthJaas policy - this will use JAAS interceptor, etc. I think
> the policies are more interesting when we can expect some interoperability but
> also when a series of interceptors is needed to validate a single requirement...
>
> So I'd start with the direct coding first Cheers, Sergey
>
>
>
> > Thanks
> > Oli
> >
> >
> >
> >
> > ------
> >
> > Oliver Wulff
> >
> > Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
> > Solution Architect
> > http://coders.talend.com
> >
> > <http://coders.talend.com>Talend Application Integration Division
> > http://www.talend.com
> >
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
Re: REST security enhancements
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Oli
On 05/02/14 19:56, Oliver Wulff wrote:
> Hi there
>
> For the REST services of the Fediz IDP I'd like to support initially three security use cases.
>
> 1) Basic Authentication, Username/Password validated against the STS
> 2) Basic Authentication, Username/Password validated with JAAS
I guess realistically, in case of Basic, it is either 1 or 2
> 3) SAML token in Basic Authorization header
>
> In CXF 3.0, each REST security interceptor enforces the security credentials it supports. Therefore, you can't just configure all interceptors like:
> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor
> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler
> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter
>
> The interceptors should not throw an exception but instead assert the token (similar the policy) and finally an interceptor checks whether one token was provided and successfully validated.
>
> Other ideas?
>
I'll be OK with the individual interceptors enforcing it. Otherwise we'd
need to chain them, etc, but having a basic delegating interceptor which
would check the authorization scheme and do something like:
public void handleMessage(Message message) {
if (isBasic(message.get(Message.REQUEST_HEADERS))) {
basicAuthInterceptor.handleMessage(message);
} else {
samlInterceptor.handleMessage(message);
}
Some basic policy support can be thought of as well, as you said, for
example, we can have a BasicAuthJaas policy - this will use JAAS
interceptor, etc. I think the policies are more interesting when we can
expect some interoperability but also when a series of interceptors is
needed to validate a single requirement...
So I'd start with the direct coding first
Cheers, Sergey
> Thanks
> Oli
>
>
>
>
> ------
>
> Oliver Wulff
>
> Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/>
> Solution Architect
> http://coders.talend.com
>
> <http://coders.talend.com>Talend Application Integration Division http://www.talend.com
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com