Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 60DFA106D9 for ; Wed, 19 Feb 2014 12:29:56 +0000 (UTC) Received: (qmail 22490 invoked by uid 500); 19 Feb 2014 12:29:53 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 22145 invoked by uid 500); 19 Feb 2014 12:29:52 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 22128 invoked by uid 99); 19 Feb 2014 12:29:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Feb 2014 12:29:51 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of owulff@talend.com designates 64.95.72.217 as permitted sender) Received: from [64.95.72.217] (HELO mxout.myoutlookonline.com) (64.95.72.217) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Feb 2014 12:29:44 +0000 Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0A5C0553517 for ; Wed, 19 Feb 2014 07:29:24 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from S10HUB001.SH10.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5684B557166 for ; Wed, 19 Feb 2014 07:29:17 -0500 (EST) Received: from S10BE002.SH10.lan ([::1]) by S10HUB001.SH10.lan ([::1]) with mapi id 14.01.0438.000; Wed, 19 Feb 2014 07:29:16 -0500 From: Oliver Wulff To: "dev@cxf.apache.org" Subject: RE: REST security enhancements Thread-Topic: REST security enhancements Thread-Index: Ac8iq6EGdp24F6EFQru0rZWCm10rFQANo3EAAA3kNwAAEZkqgP//0LWVgABqc4D/+4l9wIAYVOiZ Date: Wed, 19 Feb 2014 12:29:16 +0000 Message-ID: <79AB4452999C844D9920E0363533273111AA297B@S10BE002.SH10.lan> References: <79AB4452999C844D9920E0363533273111A8BED5@S10BE002.SH10.lan> <52F2AB6A.1040304@gmail.com> ,<52F37EBD.1080208@gmail.com> <79AB4452999C844D9920E0363533273111A8C28C@S10BE002.SH10.lan> <52F3B05D.8050404@gmail.com>, In-Reply-To: Accept-Language: en-GB, de-DE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.254.155.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Hi Sergey, Andrei=0A= =0A= >>>=0A= However from my perspective it could be interesting to change "requirements= " and "capabilities" for JAXRS endpoint dynamically. That means that all re= levant interceptors are prepared and configured, but decision which from th= em should go into chain for the current message is made dynamically (based = on policy language, configuration, etc )=0A= >>>=0A= =0A= I agree that a REST service provider can configure the interceptors with al= l required configurations like keystores etc. Then I see two options:=0A= 1) All security interceptors are in the chain which means they don't fail i= n case of one security interceptor fails and a final interceptor will enfor= ce security or not based on some configuration.=0A= 2) A single interceptor which dynamically check which interceptor is able t= o handle the current request (canHandleToken/canHandleRequest or policyexpr= ession). This requires an interface for the security interceptor to know wh= ich interceptor can handle a request or which security standard is supporte= d by an interceptor. =0A= =0A= IMHO, I'd prefer option 2 as exception handling is a bit more tricky in opt= ion 1 and the purpose of the interceptor is clear.=0A= =0A= Thanks=0A= Oli=0A= =0A= =0A= ________________________________________=0A= From: Andrei Shakirin [ashakirin@talend.com]=0A= Sent: 09 February 2014 18:19=0A= To: dev@cxf.apache.org=0A= Subject: RE: REST security enhancements=0A= =0A= Hi Sergei,=0A= =0A= > -----Original Message-----=0A= > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]=0A= > Sent: Donnerstag, 6. Februar 2014 16:55=0A= > To: dev@cxf.apache.org=0A= > Subject: Re: REST security enhancements=0A= >=0A= > Hi Oli=0A= > On 06/02/14 14:38, Oliver Wulff wrote:=0A= > > Hi Sergey=0A= > >=0A= > > I understand what you mean effort wise but I would also like some sort= of=0A= > features Andrei is asking for. To rewrite or invent a new policy language= is a=0A= > big step. Maybe we can find something in between like:=0A= > >=0A= > > Some sort of SecurityInterceptor interface where the implementation tel= ls=0A= > what kind of credential it is able to handle (similar to the STS=0A= > TokenProvider/Validator, etc.) and the DelegationInterceptor interates th= rough=0A= > the list to find the interceptor who is capable in handling the incoming= =0A= > credentials.=0A= > >=0A= > > Otherwise, it's quite static and not extendible by having something lik= e:=0A= > > if (isBasic()) {=0A= > > else if (isOAuth()) {=0A= > > else if (isSamlP()) {=0A= > > else if (isWSFed()) {=0A= > > ....=0A= > >=0A= > > WDYT?=0A= >=0A= > The interceptors enforcing multiple authentication mechanisms will come f= rom=0A= > different modules, and we also have Kerberos, and custom authorization=0A= > schemes (example with all sort of OAuth2 tokens); creating a catch-all se= curity=0A= > interceptor is possible in principle but having such an interceptor shipp= ed is not=0A= > very realistic IMHO.=0A= >=0A= > By the way, what I meant about the effort: if it can give the real benefi= t then it=0A= > is not a problem spending time implementing it. The effort I was referrin= g to is=0A= > about doing a basic interceptor manually vs configuring some catch-all=0A= > interceptor and at the moment it is not obvious to me where this vs. stan= ds in=0A= > the RS case.=0A= >=0A= > Are you interested in the automating the way the security configuration i= s=0A= > done, or would like to have a Java-First endpoint with some basic policy= =0A= > expression which will give a hint to the runtime what needs to be done ?= =0A= >=0A= > The latter option might work in principle - we may have different JAX-RS= =0A= > modules contributing security interceptors check for the conditions and e= ither=0A= > ignore or enforce the security as needed.=0A= >=0A= > This might be worth considering=0A= =0A= Well, the completely automated configuration IMO is quite difficult to achi= eve, because normally it is necessary to configure parameters specific for = security schema as well (keystores, aliases, callbacks, etc)=0A= However from my perspective it could be interesting to change "requirements= " and "capabilities" for JAXRS endpoint dynamically. That means that all re= levant interceptors are prepared and configured, but decision which from th= em should go into chain for the current message is made dynamically (based = on policy language, configuration, etc )=0A= =0A= Regards,=0A= Andrei.=0A= =0A= >=0A= > Cheers, Sergey=0A= >=0A= > >=0A= > > Thanks=0A= > > Oli=0A= > >=0A= > >=0A= > >=0A= > > ________________________________________=0A= > > From: Sergey Beryozkin [sberyozkin@gmail.com]=0A= > > Sent: 06 February 2014 13:23=0A= > > To: dev@cxf.apache.org=0A= > > Subject: Re: REST security enhancements=0A= > >=0A= > > Hi Andrei=0A= > > On 06/02/14 09:06, Andrei Shakirin wrote:=0A= > >> Hi Sergei,=0A= > >>=0A= > >> For me is also interesting to have a simple way to configure REST serv= ice=0A= > with authentication schemas it accepts.=0A= > >> For example one service will accept only SAML, second service accepts= =0A= > either Basic Auths or SAML, depending what client sent.=0A= > >> For SOAP services that is quite easy to do using WS-Policy assertions.= =0A= > >> Do you think kind of similar mechanism is useful for REST?=0A= > >>=0A= > > Right, awhile back I was keen to get a simple policy language=0A= > > introduced so that, for example, WADL can contain simple extensions=0A= > > like , etc=0A= > >=0A= > > Now, moving into the the alternatives for a single endpoint=0A= > > complicates things a bit, with ExactlyOnce, etc,=0A= > >=0A= > > The question, does it make sense to mimic a WS-Policy language, and if= =0A= > > yes, how far shall we go.=0A= > >=0A= > > Another question is how likely can we get some interoperability here,= =0A= > > which is what I referred to earlier, with WS all WS-Policy aware=0A= > > clients, non-CXF including, will manage it, based on the fact (mostly)= =0A= > > that WSDL is one of the key pieces enabling the communication.=0A= > >=0A= > > This is why I'm a bit hesitant right now of having to invest much into= =0A= > > it; for example, the cost of supporting a number of authentication=0A= > > alternatives per a given RS endpoint via the policy-like language can= =0A= > > be bigger than hacking a delegating interceptor - the problem with the= =0A= > > manual approach is of course is that it can not be properly supported= =0A= > > at the tooling/modeling level, etc, but on the plus side - well it=0A= > > just works :-).=0A= > >=0A= > > That said, I think it makes sense to investigate what simple language= =0A= > > we can come up with for describing simple RS (security) policies,=0A= > > example, a single statement, simple alternatives without the extra=0A= > > configuration for a start, etc...=0A= > >=0A= > > Thanks, Sergey=0A= > >=0A= > >> Regards,=0A= > >> Andrei.=0A= > >>=0A= > >>> -----Original Message-----=0A= > >>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]=0A= > >>> Sent: Mittwoch, 5. Februar 2014 22:22=0A= > >>> To: dev@cxf.apache.org=0A= > >>> Subject: Re: REST security enhancements=0A= > >>>=0A= > >>> Hi Oli=0A= > >>> On 05/02/14 19:56, Oliver Wulff wrote:=0A= > >>>> Hi there=0A= > >>>>=0A= > >>>> For the REST services of the Fediz IDP I'd like to support=0A= > >>>> initially three security=0A= > >>> use cases.=0A= > >>>>=0A= > >>>> 1) Basic Authentication, Username/Password validated against the=0A= > >>>> STS=0A= > >>>> 2) Basic Authentication, Username/Password validated with JAAS=0A= > >>> I guess realistically, in case of Basic, it is either 1 or 2=0A= > >>>=0A= > >>>> 3) SAML token in Basic Authorization header=0A= > >>>>=0A= > >>>> In CXF 3.0, each REST security interceptor enforces the security=0A= > >>>> credentials it=0A= > >>> supports. Therefore, you can't just configure all interceptors like:= =0A= > >>>> org.apache.cxf.ws.security.trust.AuthPolicyValidatingInterceptor=0A= > >>>> org.apache.cxf.rs.security.saml.SamlEnvelopedInHandler=0A= > >>>> org.apache.cxf.jaxrs.security.JAASAuthenticationFilter=0A= > >>>>=0A= > >>>> The interceptors should not throw an exception but instead assert=0A= > >>>> the token=0A= > >>> (similar the policy) and finally an interceptor checks whether one=0A= > >>> token was provided and successfully validated.=0A= > >>>>=0A= > >>>> Other ideas?=0A= > >>>>=0A= > >>> I'll be OK with the individual interceptors enforcing it. Otherwise= =0A= > >>> we'd need to chain them, etc, but having a basic delegating=0A= > >>> interceptor which would check the authorization scheme and do somethi= ng=0A= > like:=0A= > >>>=0A= > >>> public void handleMessage(Message message) { if=0A= > >>> (isBasic(message.get(Message.REQUEST_HEADERS))) {=0A= > >>> basicAuthInterceptor.handleMessage(message);=0A= > >>> } else {=0A= > >>> samlInterceptor.handleMessage(message);=0A= > >>> }=0A= > >>>=0A= > >>> Some basic policy support can be thought of as well, as you said,=0A= > >>> for example, we can have a BasicAuthJaas policy - this will use JAAS= =0A= > >>> interceptor, etc. I think the policies are more interesting when we= =0A= > >>> can expect some interoperability but also when a series of intercepto= rs is=0A= > needed to validate a single requirement...=0A= > >>>=0A= > >>> So I'd start with the direct coding first Cheers, Sergey=0A= > >>>=0A= > >>>=0A= > >>>=0A= > >>>> Thanks=0A= > >>>> Oli=0A= > >>>>=0A= > >>>>=0A= > >>>>=0A= > >>>>=0A= > >>>> ------=0A= > >>>>=0A= > >>>> Oliver Wulff=0A= > >>>>=0A= > >>>> Blog: http://owulff.blogspot.com=0A= > >>>> Solution Architect=0A= > >>>> http://coders.talend.com=0A= > >>>>=0A= > >>>> Talend Application Integration Division=0A= > >>>> http://www.talend.com=0A= > >>>>=0A= > >>>=0A= > >>>=0A= > >>> --=0A= > >>> Sergey Beryozkin=0A= > >>>=0A= > >>> Talend Community Coders=0A= > >>> http://coders.talend.com/=0A= > >>>=0A= > >>> Blog: http://sberyozkin.blogspot.com=0A= > >=0A= > >=0A= >=0A= >=0A= > --=0A= > Sergey Beryozkin=0A= >=0A= > Talend Community Coders=0A= > http://coders.talend.com/=0A= >=0A= > Blog: http://sberyozkin.blogspot.com=0A=