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 [ashaki...@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:sberyoz...@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 [ashaki...@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:sberyoz...@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 [sberyoz...@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:sberyoz...@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
