cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Wulff <>
Subject RE: REST security enhancements
Date Thu, 06 Feb 2014 14:38:39 GMT
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

Otherwise, it's quite static and not extendible by having something like:
if (isBasic()) {
else if (isOAuth()) {
else if (isSamlP()) {
else if (isWSFed()) {



From: Sergey Beryozkin []
Sent: 06 February 2014 13:23
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 []
>> Sent: Mittwoch, 5. Februar 2014 22:22
>> To:
>> 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
>> supports. Therefore, you can't just configure all interceptors like:
>>> 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:<>
>>> Solution Architect
>>> <>Talend Application Integration Division
>> --
>> Sergey Beryozkin
>> Talend Community Coders
>> Blog:

View raw message