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
