Hi
How about this for a start:
http://git-wip-us.apache.org/repos/asf/cxf/blob/55a4b7bf/core/src/main/java/org/apache/cxf/interceptor/security/DelegatingAuthenticationInterceptor.java
?
all this interceptor does is it delegates to the authentication scheme
specific handler
Thanks, Sergey
On 19/02/14 12:29, Oliver Wulff wrote:
Hi Sergey, Andrei
However from my perspective it could be interesting to change "requirements" and
"capabilities" for JAXRS endpoint dynamically. That means that all relevant interceptors
are prepared and configured, but decision which from them should go into chain for the current
message is made dynamically (based on policy language, configuration, etc )
I agree that a REST service provider can configure the interceptors with all
required configurations like keystores etc. Then I see two options:
1) All security interceptors are in the chain which means they don't fail in
case of one security interceptor fails and a final interceptor will enforce
security or not based on some configuration.
2) A single interceptor which dynamically check which interceptor is able to
handle the current request (canHandleToken/canHandleRequest or
policyexpression). This requires an interface for the security interceptor to
know which interceptor can handle a request or which security standard is
supported by an interceptor.
IMHO, I'd prefer option 2 as exception handling is a bit more tricky in option
1 and the purpose of the interceptor is clear.
Thanks
Oli
________________________________________
From: Andrei Shakirin [[email protected]]
Sent: 09 February 2014 18:19
To: [email protected]
Subject: RE: REST security enhancements
Hi Sergei,
-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: Donnerstag, 6. Februar 2014 16:55
To: [email protected]
Subject: Re: REST security enhancements
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
Well, the completely automated configuration IMO is quite difficult to achieve,
because normally it is necessary to configure parameters specific for security
schema as well (keystores, aliases, callbacks, etc)
However from my perspective it could be interesting to change "requirements" and
"capabilities" for JAXRS endpoint dynamically. That means that all relevant interceptors
are prepared and configured, but decision which from them should go into chain for the current
message is made dynamically (based on policy language, configuration, etc )
Regards,
Andrei.
Cheers, Sergey
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
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
