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 [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