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


Reply via email to