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
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
