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 [[email protected]]
Sent: 06 February 2014 13:23
To: [email protected]
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:[email protected]]
>> Sent: Mittwoch, 5. Februar 2014 22:22
>> To: [email protected]
>> 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
