You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2010/04/07 16:11:21 UTC
Using WS-Security UsernameToken to authenticate users and populate
SecurityContexts
Hi
I've been looking recently at extending the CXF WS-Security component such
that a current UsernameToken could be used by custom interceptors
to authenticate a user with the external security systems and, if possible,
provide enough information for CXF to populate a SecurityContext [1] to be
used later on for
authorization decisions.
Here is the approach I've taken so far.
A custom interceptor extends
AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method it
overrides is
abstract Subject createSubject(String name, String password, boolean isDigest,
String nonce,
String created) throws WSSecurityException;
For example, see [3].
The idea here is that a custom interceptor interfaces whichever way it needs
to with the external system and populates a Subject following this simple
rule : first Subject principal is the current user (identified by a 'name'
argument), followed by one or more Groups this user is a member of.
AbstractWSS4JSecurityContextProvidingInterceptor will use this Subject to
provide a functional SecurityContext instance.
This is the first part, next is how to utilize a SecurityContext and get the
expected roles associated one way or the other with a current method to be
invoked. There's a number of usual options available here, perhaps even
SpringSecurity can be used now that SecurityContext is available, or
application code or other custom CXF interceptor can check the known roles
against SecurityContext.
I've also added AbstractAuthorizingInInterceptor interceptor which custom
interceptors can override and return a list of expected roles given a
(service) Method to be invoked upon, AbstractAuthorizingInInterceptor will
then ask available SecurityContext to match the roles; one concrete
implementation is SimpleAuthorizingInterceptor[5], it can be injected with a
method specific or class (applying to all methods) roles. Another
implementation which I will likely add later on will be injected with a name
of annotation such as RolesAlloved and it will introspect a method and its
class.
Note that I haven't looked into the case when a policy runtimes adds the
interceptors yet (as opposed to interceptors being configured form
Spring/programmatically). I think an optional contextual property will need
to be setup in such cases for users be able to indicate that say an
interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
etc.
I'm going to validate this approach with JBoss CXF. If you have any comments
then please let me know.
I think we may have a simpler alternative eventually to the way
authorization decisions are made. [1]-[3] is specific to ws-security, but
[4]-[5] is not
cheers, Sergey
[1] https://issues.apache.org/jira/browse/CXF-2754
[2]
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor.java
[3]
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/apache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java
[4]
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/AbstractAuthorizingInInterceptor.java
[5]
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/SimpleAuthorizingInterceptor.java
Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Posted by Daniel Kulp <dk...@apache.org>.
Sergey,
BTW: I DID add a system test of the optimized UsernameToken processing:
https://svn.apache.org/viewvc?view=revision&revision=924117
Dan
On Friday 09 April 2010 9:50:45 am Daniel Kulp wrote:
> My main "concern" with the implementation of this is that it's done as a
> direct subclass of the WSS4JInInterceptor and thus not really usable by the
> policy based endpoints as those interceptors subclass WSS4JInInterceptor as
> well.
>
> I think the better approach may be to add a flag to wss4j (I can help
> commit changes there if needed) to have it not do any UserName token
> processing at all. (aside: this may be doable without changes to wss4j
> by registering our own "do nothing processor") Then, have another
> interceptor that runs after the WSS4JInInterceptor that would actually
> handle the UsernameToken and verify anything it needs and such.
>
> To be honest, I WANT to do this for the Policy based stuff anyway. There
> is currently some duplicated code between the
> PolicyBasedWSS4JIinInterceptor and the new UsernameTokenInterceptor that
> could be eliminated by having the PolicyBasedWSS4JIinInterceptor not do
> UsernameTokens at all and delegate that completely to the
> UsernameTokenInterceptor.
>
> Basically, it would be good if the WSS4JIn* stuff just handled the
> encryption/signature stuff and then let the authorization validations stuff
> to later interceptors. That would include things like key validation
> checking and stuff as well. Probably SAML token validation as well.
>
> Dan
>
> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
> > Hi David
> >
> > thanks for the comments...
> >
> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org> wrote:
> > > Sergey,
> > >
> > > I think this type of functionality would be very useful to a number of
> > > folks. I have built two similar capabilities for clients very recently
> > > using CXF and Spring Security. Based on the code provided below, I
> > > have several points that I would like to see addressed in a solution.
> > >
> > > 1) Architecture to support more than just UsernameTokens. I have
> > > worked with systems that need to authenticate a user using
> > > UsernameTokens, BinarySecurityTokens, SAML Assertions, and a
> > > combination of more than one of
> > > these at a time.
> >
> > Supporting UsernameTokens is the initial requirement. At the moment I do
> > not even know how BinarySecurityTokens or SAML Assertions are
> > processed/validated in CXF or WSS4J.
> >
> > > For the most part, WSS4J simply validates the structural
> > > details of security. That is, signature validity, trust chaining of
> > > digital
> > > certificates, etc. As Glen pointed out with his reference to
> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes performs
> > > its
> > > own password checking (authentication). Unfortunately, WSS4J doesn't
> > > provide hooks for authenticating other forms of credentials that I have
> > > listed above (I don't consider trust to be equivalent to
> > > authentication). It would be best if the authentication interface
> > > supported multiple credential types and allowed for authentication to
> > > be performed in a single location in the same manner every time (not
> > > sometimes in the WSS4J callback and sometimes in another interceptor
> > > for non-UT based credentials).
> >
> > Makes sense. Assuming it is WSS4J which validates (the structure of)
> > BinarySecurityTokens then
> > AbstractWSS4JSecurityContextProvidingInterceptor can also implement a
> > processor for BinarySecurityTokens and delegate to subclass to
> > authenticate and setup a subject. Some extra methods will need to be
> > added, to be optionally overridden.
> >
> > If it is not only WSS4J which is involved then perhaps another option is
> > to store (from WSS4J callback handler, etc) relevant details such
> > username token details, etc to be acted upon by other interceptors.
> >
> > > That
> > > last bit there means disabling WSS4J's password authentication since it
> > > gets
> > > in the way of doing it later in our own interceptor.
> >
> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
> > implementing a simplified UsernameTokenProcessor
> >
> > > 2) Allow for end-user flexibility in choosing the credentials they want
> > > to authenticate. For instance, each user is going to have their own
> > > security profiles and authentication requirements. For instance, a
> > > message contains a UT for a portal user and a digital signature from
> > > the portal (I know using
> > > a SAML Assertion would be better here, but people still do it this
> > > way). Each organization will have different requirements as to which
> > > credentials get authenticated and what needs to end up in the security
> > > context.
> >
> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
> > should be able to do it, for username tokens and other tokens later on.
> >
> > > 3) Decouple the authentication interface from WSS4J. What is passed in
> > > needs to be abstracted enough that it can work with other WS-Security
> > > libraries as well.
> >
> > the only WSS4J class which is leaked at the moment is
> > WSSecurityException. Perhaps we can come up later on with a different
> > more generic approach which does not depend on WSS4J at all. As Dan
> > indicated, in some cases WSS4JInInterceptor is not even used, so that
> > case will need to be addressed. Experimenting wuth binary tokens might
> > help with identifying another solution.
> >
> > > 4) It would be nice to be able to perform authorization using something
> > > like
> > > Spring Security at the service operation level. With a POJO or JAX-WS
> > > based
> > > service, one can just use Spring Security's method interceptor to
> > > provide such security; however, in situations where one only has a
> > > WSDL based service or a provider style service, a method interceptor
> > > can't be used.
> > >
> > > It
> > >
> > > would be nice to provide a hook into Spring Security to allow end-users
> > > to specify role based authorization policy based on a combination of
> > > interface,
> > > instance, and operation names. It seems like your
> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
> > > looking in this direction, but I think it would be best if we can stand
> > > on the shoulders of the Spring Security giant as much as possible so
> > > that we can take advantage of their rich authorization manager, voter,
> > > XML
> > > configuration
> > > capabilities.
> >
> > Not sure what to say here yet. But I think non-Spring users should be
> > taken care of too. Or when simpler cases are dealt with then perhaps
> > there's no need to bring in Spring security. Perhaps the utility
> > authorization interceptors should just not be used when Spring Security
> > is preferred ?
> >
> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The CXF-BC
> > > currently has a limited capability to select the credentials to
> > > authenticate
> > > and would benefit from 1 and 2 above. The CXF-BC ultimately delegates
> > > authentication to the JBI container through a ServiceMix components
> > > authentication service abstraction of JAAS. Whatever solution we have
> > > for 1
> > > and 2 would help out the component if the ServiceMix authentication
> > > service abstraction could be wired up in lieu of whatever we provide
> > > out of the box.
> >
> > I'm not planning to contribute to ServiceMix. I agree though that an
> > ideal solution will meet multiple requirements
> >
> > thanks, Sergey
> >
> > > -----Original Message-----
> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> > > Sent: Wednesday, April 07, 2010 10:11 AM
> > > To: dev@cxf.apache.org
> > > Subject: Using WS-Security UsernameToken to authenticate users and
> > > populate SecurityContexts
> > >
> > > Hi
> > >
> > > I've been looking recently at extending the CXF WS-Security component
> > > such that a current UsernameToken could be used by custom interceptors
> > > to authenticate a user with the external security systems and, if
> > > possible, provide enough information for CXF to populate a
> > > SecurityContext [1] to be used later on for
> > > authorization decisions.
> > >
> > > Here is the approach I've taken so far.
> > > A custom interceptor extends
> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
> > > method it overrides is
> > >
> > > abstract Subject createSubject(String name, String password, boolean
> > > isDigest,
> > >
> > > String nonce,
> > > String created) throws
> > >
> > > WSSecurityException;
> > >
> > >
> > > For example, see [3].
> > >
> > > The idea here is that a custom interceptor interfaces whichever way it
> > > needs
> > > to with the external system and populates a Subject following this
> > > simple rule : first Subject principal is the current user (identified
> > > by a 'name' argument), followed by one or more Groups this user is a
> > > member of. AbstractWSS4JSecurityContextProvidingInterceptor will use
> > > this Subject to provide a functional SecurityContext instance.
> > >
> > > This is the first part, next is how to utilize a SecurityContext and
> > > get the
> > > expected roles associated one way or the other with a current method to
> > > be invoked. There's a number of usual options available here, perhaps
> > > even SpringSecurity can be used now that SecurityContext is available,
> > > or application code or other custom CXF interceptor can check the known
> > > roles against SecurityContext.
> > >
> > > I've also added AbstractAuthorizingInInterceptor interceptor which
> > > custom interceptors can override and return a list of expected roles
> > > given a (service) Method to be invoked upon,
> > > AbstractAuthorizingInInterceptor will then ask available
> > > SecurityContext to match the roles; one concrete implementation is
> > > SimpleAuthorizingInterceptor[5], it can be injected with a
> > > method specific or class (applying to all methods) roles. Another
> > > implementation which I will likely add later on will be injected with a
> > > name
> > > of annotation such as RolesAlloved and it will introspect a method and
> > > its class.
> > >
> > > Note that I haven't looked into the case when a policy runtimes adds
> > > the interceptors yet (as opposed to interceptors being configured form
> > > Spring/programmatically). I think an optional contextual property will
> > > need to be setup in such cases for users be able to indicate that say
> > > an interceptor such as [3] has to be used as opposed to
> > > WSS4JInInterceptor, etc.
> > >
> > > I'm going to validate this approach with JBoss CXF. If you have any
> > > comments
> > > then please let me know.
> > >
> > > I think we may have a simpler alternative eventually to the way
> > > authorization decisions are made. [1]-[3] is specific to ws-security,
> > > but [4]-[5] is not
> > >
> > > cheers, Sergey
> > >
> > > [1] https://issues.apache.org/jira/browse/CXF-2754
> > > [2]
> > >
> > > http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/
> > > or g/a
> > >
> > > pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterc
> > > ep
> > > tor<http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/
> > > jav
> > > a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProv
> > > idi ngInterceptor> .java
> > > [3]
> > >
> > > http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/
> > > or g/a
> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:
> > > /
> > > /svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a
> > > %0A pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
> > > [4]
> > >
> > > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apa
> > > ch e/c
> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<http://sv
> > > n
> > > .apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Ax
> > > f/i nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
> > >
> > > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apa
> > > ch e/c
> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<http://svn.ap
> > > a
> > > che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/in
> > > ter ceptor/security/SimpleAuthorizingInterceptor.java>
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
I'm going to merge [1]
into 2.2.8-SNAPSHOT. Note that for a java-first case I've renamed
AbstractWSS4JSecurityContextProvidingInterceptor to
AbstractUsernameTokenAuthenticatingInterceptor (and this is still a bit too
long, will likely remain tomorrow to
AbstractUsernameAuthenticatingInterceptor), for it to reflect better what
its goal is; for a policy-first case [1] does not even introduce any new
interceptors but just makes it possible for users to extend
UsernameTokenInterceptor, when only UT is involved...
The only bit I'm not 100% happy about is that users would need to indicate
(in a policy first case), through the use of a bus property, that a custom
interceptor has to be registered instead. I guess the policy engine can be
extended somehow later so that users configure a policy engine instead...
cheers, Sergey
[1] http://svn.apache.org/viewvc?rev=936521&view=rev<http://svn.apache.org/viewvc?rev=936521&view=rev>
On Wed, Apr 21, 2010 at 10:47 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> I added a system test for a policy first case and refactored few bits along
> the way, as well as closed [1] as 'Wont fix', at least for now.
>
> I've just updated UsernameTokenInterceptor[1] so that a (WSS4J) principal
> can be created directly if a message property disabling the validation of
> passwords has been set.
>
> This property can be set as a jaxws contextual property in which case
> interceptors further in the chain will be able to get the (unauthenticated)
> Principal, validate it, and set a SecurityContext as needed.
>
> Another approach used in the system test is to write a custom
> interceptor[3] extending UsernameTokenInterceptor and disable the validation
> from there. This custom interceptor is currently being registered by setting
> a bus property, see [4]. Note that a jaxws endpoint adds
> SimpleAuthorizationInterceptor only and has no callbacks registered.
>
> See [5] for more details.
>
> It looks quite reasonable to me at the moment, perhaps there could be a
> simpler way to register custom interceptors.
>
> Dan, you've mentioned the fact you were planning to refactor some of the
> policy interceptors so that WSS4JInterceptor is not used for UsernameToken
> processing at all. I'd appreciate if you could look into this refactoring
> yourself, there could be some subtleties there I'm not aware of. Also,
> personally I'd prefer registering a noop processor with WSS4J rather adding
> a flag to WSS4J, perhaps this noop processor can be used for handling other
> types of tokens, using an approach similar to the one taken by
> UsernameTokenInterceptor, unless yourself, David V, others have something
> else in mind...
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/WSS-229
> [2]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
> [3]
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java
> [4]
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml
> [5] http://svn.apache.org/viewvc?rev=936521&view=rev
>
>
>
> On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
>
>> Hi
>>
>> I've added an initial patch for addressing a policy-first case, see [1].
>> It's a patch because it depends on another one I submitted to WSS4J [2].
>> Both patches need more work (tests, etc) but I'd just like to initiate a
>> discussion/review.
>>
>> The idea behind [1] is quite similar to the one used in supporting a
>> java-first case, where a custom interceptor extends an
>> AbstractWSS4JSecurityContextPr
>> oviding interceptor. But is is much simpler in [1] where
>> UsernameTokenProcessor may be optionally extended and its createSubject
>> method be overridden. Provided [2] gets applied then a subclass will just
>> have a property set disabling the (WSS4J) validation of passwords and will
>> do its own validation in createSubject method.
>>
>> This is really all what will be needed in simple cases, where a
>> DefaultSecurityContext will do, but optionally, createSecurityContext can
>> be overridden too.
>>
>> A user would need to set a bus property
>> "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a custom
>> interceptor which will indicate to the WSSecurityPolicyLoader that a custom
>> UsernameTokenProcessor subclass will need to be loaded.
>>
>> Similar approach can be employed for handling other types of tokens.
>>
>> cheers, Sergey
>>
>> [1] https://issues.apache.org/jira/browse/CXF-2754
>> [2] https://issues.apache.org/jira/browse/WSS-229
>>
>>
>> On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
>>
>>> Just realized I did not CC tp dev when replying to Dan the other day :
>>>
>>> Hi Dan
>>>
>>>
>>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>>
>>>> My main "concern" with the implementation of this is that it's done as a
>>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>>> the
>>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>>> as
>>>> well.
>>>>
>>>> I think the better approach may be to add a flag to wss4j (I can help
>>>> commit
>>>> changes there if needed) to have it not do any UserName token processing
>>>> at
>>>> all. (aside: this may be doable without changes to wss4j by
>>>> registering our
>>>> own "do nothing processor") Then, have another interceptor that runs
>>>> after
>>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>>> verify
>>>> anything it needs and such.
>>>>
>>>
>>> This sounds like a very good idea, I agree the proposed approach won't do
>>> for the cases where policies drive the
>>> creation of interceptors.
>>>
>>> Having said that, I think the abstract utility interceptor extending
>>> WSS4JInInterceptor
>>> may still be used in cases where users start from manually configuring
>>> jaxws endpoints. In these cases they'd need to
>>> list up to 3 interceptors (the one which extends
>>> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if the
>>> authorization is needed plus may be a SAAJ one) but otherwise, when say a
>>> clear text password has been encrypted, they'd still need to specify
>>> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
>>> UsernameTokenInterceptor, etc.
>>>
>>> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit complicated
>>> due to the fact it blocks the WSS4J digest checks and thus also creates a
>>> security engine per every request, but it all will be gone in due time...
>>>
>>>
>>>>
>>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>>> There is
>>>> currently some duplicated code between the
>>>> PolicyBasedWSS4JIinInterceptor and
>>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>>> that
>>>> completely to the UsernameTokenInterceptor.
>>>>
>>>
>>> What I will do is I will experiment with the test you added (thanks :-))
>>> and see how UsernameTokenInterceptor can be refactored
>>> so that a subclass can get an easy access to password, nonce, etc. I
>>> think I will need to come up with a contextual property so that a custom
>>> UsernameTokenInterceptor can be installed if needed. Or may be
>>> UsernameTokenInterceptor can store the details in a message to be later
>>> retrieved and processed for creating SecurityContext - but I'm not sure
>>> about it just yet.
>>>
>>>
>>>>
>>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>>> encryption/signature stuff and then let the authorization validations
>>>> stuff to
>>>> later interceptors. That would include things like key validation
>>>> checking
>>>> and stuff as well. Probably SAML token validation as well.
>>>>
>>>>
>>> sounds good
>>>
>>> cheers, Sergey
>>>
>>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>>
>>>> My main "concern" with the implementation of this is that it's done as a
>>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>>> the
>>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>>> as
>>>> well.
>>>>
>>>> I think the better approach may be to add a flag to wss4j (I can help
>>>> commit
>>>> changes there if needed) to have it not do any UserName token processing
>>>> at
>>>> all. (aside: this may be doable without changes to wss4j by
>>>> registering our
>>>> own "do nothing processor") Then, have another interceptor that runs
>>>> after
>>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>>> verify
>>>> anything it needs and such.
>>>>
>>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>>> There is
>>>> currently some duplicated code between the
>>>> PolicyBasedWSS4JIinInterceptor and
>>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>>> that
>>>> completely to the UsernameTokenInterceptor.
>>>>
>>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>>> encryption/signature stuff and then let the authorization validations
>>>> stuff to
>>>> later interceptors. That would include things like key validation
>>>> checking
>>>> and stuff as well. Probably SAML token validation as well.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
>>>> > Hi David
>>>> >
>>>> > thanks for the comments...
>>>> >
>>>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
>>>> wrote:
>>>> > > Sergey,
>>>> > >
>>>> > > I think this type of functionality would be very useful to a number
>>>> of
>>>> > > folks. I have built two similar capabilities for clients very
>>>> recently
>>>> > > using CXF and Spring Security. Based on the code provided below, I
>>>> have
>>>> > > several points that I would like to see addressed in a solution.
>>>> > >
>>>> > > 1) Architecture to support more than just UsernameTokens. I have
>>>> worked
>>>> > > with systems that need to authenticate a user using UsernameTokens,
>>>> > > BinarySecurityTokens, SAML Assertions, and a combination of more
>>>> than one
>>>> > > of
>>>> > > these at a time.
>>>> >
>>>> > Supporting UsernameTokens is the initial requirement. At the moment I
>>>> do
>>>> > not even know how BinarySecurityTokens or SAML Assertions are
>>>> > processed/validated in CXF or WSS4J.
>>>> >
>>>> > > For the most part, WSS4J simply validates the structural
>>>> > > details of security. That is, signature validity, trust chaining of
>>>> > > digital
>>>> > > certificates, etc. As Glen pointed out with his reference to
>>>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
>>>> performs
>>>> > > its
>>>> > > own password checking (authentication). Unfortunately, WSS4J
>>>> doesn't
>>>> > > provide hooks for authenticating other forms of credentials that I
>>>> have
>>>> > > listed above (I don't consider trust to be equivalent to
>>>> authentication).
>>>> > > It would be best if the authentication interface supported multiple
>>>> > > credential types and allowed for authentication to be performed in a
>>>> > > single location in the same manner every time (not sometimes in the
>>>> > > WSS4J callback and sometimes in another interceptor for non-UT based
>>>> > > credentials).
>>>> >
>>>> > Makes sense. Assuming it is WSS4J which validates (the structure of)
>>>> > BinarySecurityTokens then
>>>> AbstractWSS4JSecurityContextProvidingInterceptor
>>>> > can also implement a processor for BinarySecurityTokens and delegate
>>>> to
>>>> > subclass to authenticate and setup a subject. Some extra methods will
>>>> need
>>>> > to be added, to be optionally overridden.
>>>> >
>>>> > If it is not only WSS4J which is involved then perhaps another option
>>>> is to
>>>> > store (from WSS4J callback handler, etc) relevant details such
>>>> username
>>>> > token details, etc to be acted upon by other interceptors.
>>>> >
>>>> > > That
>>>> > > last bit there means disabling WSS4J's password authentication since
>>>> it
>>>> > > gets
>>>> > > in the way of doing it later in our own interceptor.
>>>> >
>>>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
>>>> > implementing a simplified UsernameTokenProcessor
>>>> >
>>>> > > 2) Allow for end-user flexibility in choosing the credentials they
>>>> want
>>>> > > to authenticate. For instance, each user is going to have their own
>>>> > > security profiles and authentication requirements. For instance, a
>>>> > > message contains a UT for a portal user and a digital signature from
>>>> the
>>>> > > portal (I know using
>>>> > > a SAML Assertion would be better here, but people still do it this
>>>> way).
>>>> > > Each organization will have different requirements as to which
>>>> > > credentials get authenticated and what needs to end up in the
>>>> security
>>>> > > context.
>>>> >
>>>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
>>>> > should be able to do it, for username tokens and other tokens later
>>>> on.
>>>> >
>>>> > > 3) Decouple the authentication interface from WSS4J. What is passed
>>>> in
>>>> > > needs to be abstracted enough that it can work with other
>>>> WS-Security
>>>> > > libraries as well.
>>>> >
>>>> > the only WSS4J class which is leaked at the moment is
>>>> WSSecurityException.
>>>> > Perhaps we can come up later on with a different more generic approach
>>>> > which does not depend on WSS4J at all. As Dan indicated, in some cases
>>>> > WSS4JInInterceptor is not even used, so that case will need to be
>>>> > addressed. Experimenting wuth binary tokens might help with
>>>> identifying
>>>> > another solution.
>>>> >
>>>> > > 4) It would be nice to be able to perform authorization using
>>>> something
>>>> > > like
>>>> > > Spring Security at the service operation level. With a POJO or
>>>> JAX-WS
>>>> > > based
>>>> > > service, one can just use Spring Security's method interceptor to
>>>> provide
>>>> > > such security; however, in situations where one only has a WSDL
>>>> based
>>>> > > service or a provider style service, a method interceptor can't be
>>>> used.
>>>> > >
>>>> > > It
>>>> > >
>>>> > > would be nice to provide a hook into Spring Security to allow
>>>> end-users
>>>> > > to specify role based authorization policy based on a combination of
>>>> > > interface,
>>>> > > instance, and operation names. It seems like your
>>>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
>>>> > > looking in this direction, but I think it would be best if we can
>>>> stand
>>>> > > on the shoulders of the Spring Security giant as much as possible so
>>>> > > that we can take advantage of their rich authorization manager,
>>>> voter,
>>>> > > XML
>>>> > > configuration
>>>> > > capabilities.
>>>> >
>>>> > Not sure what to say here yet. But I think non-Spring users should be
>>>> taken
>>>> > care of too. Or when simpler cases are dealt with then perhaps there's
>>>> no
>>>> > need to bring in Spring security. Perhaps the utility authorization
>>>> > interceptors should just not be used when Spring Security is preferred
>>>> ?
>>>> >
>>>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
>>>> CXF-BC
>>>> > > currently has a limited capability to select the credentials to
>>>> > > authenticate
>>>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
>>>> delegates
>>>> > > authentication to the JBI container through a ServiceMix components
>>>> > > authentication service abstraction of JAAS. Whatever solution we
>>>> have
>>>> > > for 1
>>>> > > and 2 would help out the component if the ServiceMix authentication
>>>> > > service abstraction could be wired up in lieu of whatever we provide
>>>> out
>>>> > > of the box.
>>>> >
>>>> > I'm not planning to contribute to ServiceMix. I agree though that an
>>>> ideal
>>>> > solution will meet multiple requirements
>>>> >
>>>> > thanks, Sergey
>>>> >
>>>> > > -----Original Message-----
>>>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>>>> > > Sent: Wednesday, April 07, 2010 10:11 AM
>>>> > > To: dev@cxf.apache.org
>>>> > > Subject: Using WS-Security UsernameToken to authenticate users and
>>>> > > populate SecurityContexts
>>>> > >
>>>> > > Hi
>>>> > >
>>>> > > I've been looking recently at extending the CXF WS-Security
>>>> component
>>>> > > such that a current UsernameToken could be used by custom
>>>> interceptors
>>>> > > to authenticate a user with the external security systems and, if
>>>> > > possible, provide enough information for CXF to populate a
>>>> > > SecurityContext [1] to be used later on for
>>>> > > authorization decisions.
>>>> > >
>>>> > > Here is the approach I've taken so far.
>>>> > > A custom interceptor extends
>>>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
>>>> method
>>>> > > it overrides is
>>>> > >
>>>> > > abstract Subject createSubject(String name, String password, boolean
>>>> > > isDigest,
>>>> > >
>>>> > > String nonce,
>>>> > > String created) throws
>>>> > >
>>>> > > WSSecurityException;
>>>> > >
>>>> > >
>>>> > > For example, see [3].
>>>> > >
>>>> > > The idea here is that a custom interceptor interfaces whichever way
>>>> it
>>>> > > needs
>>>> > > to with the external system and populates a Subject following this
>>>> simple
>>>> > > rule : first Subject principal is the current user (identified by a
>>>> > > 'name' argument), followed by one or more Groups this user is a
>>>> member
>>>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
>>>> > > Subject to provide a functional SecurityContext instance.
>>>> > >
>>>> > > This is the first part, next is how to utilize a SecurityContext and
>>>> get
>>>> > > the
>>>> > > expected roles associated one way or the other with a current method
>>>> to
>>>> > > be invoked. There's a number of usual options available here,
>>>> perhaps
>>>> > > even SpringSecurity can be used now that SecurityContext is
>>>> available,
>>>> > > or application code or other custom CXF interceptor can check the
>>>> known
>>>> > > roles against SecurityContext.
>>>> > >
>>>> > > I've also added AbstractAuthorizingInInterceptor interceptor which
>>>> custom
>>>> > > interceptors can override and return a list of expected roles given
>>>> a
>>>> > > (service) Method to be invoked upon,
>>>> AbstractAuthorizingInInterceptor
>>>> > > will then ask available SecurityContext to match the roles; one
>>>> concrete
>>>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
>>>> injected
>>>> > > with a
>>>> > > method specific or class (applying to all methods) roles. Another
>>>> > > implementation which I will likely add later on will be injected
>>>> with a
>>>> > > name
>>>> > > of annotation such as RolesAlloved and it will introspect a method
>>>> and
>>>> > > its class.
>>>> > >
>>>> > > Note that I haven't looked into the case when a policy runtimes adds
>>>> the
>>>> > > interceptors yet (as opposed to interceptors being configured form
>>>> > > Spring/programmatically). I think an optional contextual property
>>>> will
>>>> > > need to be setup in such cases for users be able to indicate that
>>>> say an
>>>> > > interceptor such as [3] has to be used as opposed to
>>>> WSS4JInInterceptor,
>>>> > > etc.
>>>> > >
>>>> > > I'm going to validate this approach with JBoss CXF. If you have any
>>>> > > comments
>>>> > > then please let me know.
>>>> > >
>>>> > > I think we may have a simpler alternative eventually to the way
>>>> > > authorization decisions are made. [1]-[3] is specific to
>>>> ws-security, but
>>>> > > [4]-[5] is not
>>>> > >
>>>> > > cheers, Sergey
>>>> > >
>>>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
>>>> > > [2]
>>>> > >
>>>> > >
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
>>>> > > g/a
>>>> > >
>>>> > >
>>>> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
>>>> > > tor<
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
>>>> > >
>>>> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
>>>> > > ngInterceptor> .java
>>>> > > [3]
>>>> > >
>>>> > >
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
>>>> > > g/a
>>>> > >
>>>> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
>>>> > > /
>>>> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
>>>> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
>>>> [4]
>>>> > >
>>>> > >
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>>> > > e/c
>>>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
>>>> http://svn
>>>> > > .
>>>> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
>>>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
>>>> > >
>>>> > >
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>>> > > e/c
>>>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
>>>> http://svn.apa
>>>> > >
>>>> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
>>>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>>>>
>>>
>>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
> After thinking about your feedback, I am thinking that having two separate
> class hierarchies to figure all of this out may be too complex. Perhaps
> something more like a JAAS configuration where you can order the
> LoginModules and declare each module's needed level of participation is
> more
> appropriate. In this way, we would have self contained profile support
> classes that can both detect if the profile they support is active and
> extract the appropriate credentials and attempt authentication. The CXF
> Interceptor could function more like a JAAS LoginContext by orchestrating
> the execution of the profile support classes and putting the results into
> the CXF message context.
>
> I'll think about this some more and try to provide some updated diagrams to
> help convey my thoughts.
>
Please do attach updated diagrams, whenever you have a chance. Seeing some
sample configuration which a user would need to employ to address, for
example, a UT case only would help in the end.
Just to clarify my current position : I look forward to seeing a better and
more comprehensive solution.
However, I'll be keen for a user to have a simple option for dealing with
UTokens which IMHO the currently proposed solution offers, given that UTs
are apparently used most often. I'll rename
'AbstractSecurityContextProvidingInterceptor' into
'AbstractUsernameTokenAuthenticatingInterceptor' or something similar to
avoid any confusions with what you propose, because it is exactly what it is
about, about doing the custom authentication of the user given the details
available in UT and then populating a security context based on the
authenticated Principal - it is all vey specific to and well understood for
UTs .
And I've no problems with 'AbstractUsernameTokenAuthenticatingInterceptor'
custom subclasses having to override a single function with a password
parameter being in the signature - users highly conscious about the security
would use digests and in case of plain passwords there're plenty of other
code paths where plain passwords are 'visible' so to say
cheers, Sergey
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Friday, April 23, 2010 1:03 PM
> To: dev@cxf.apache.org
> Subject: Re: Using WS-Security UsernameToken to authenticate users and
> populate SecurityContexts
>
> On Fri, Apr 23, 2010 at 2:53 PM, David Valeri <dv...@apache.org> wrote:
>
> > I have attached the diagrams to the ticket in JIRA.
> >
>
> thanks...
>
>
>
> >
> > The eventual interceptor that handles a profile would be specific to the
> > security implementation used as it ultimately needs to look at results
> that
> > are in a proprietary form (WSS4J, METRO, etc.). What the framework
> > provides
> > is some scaffolding to handle the boilerplate stuff such that concrete
> > interceptors only have to deal with extracting credentials and it allows
> > end
> > users to substitute their own interceptor implementations for whatever
> > profiles they need to support.
> >
>
> Now, here is a slightly alternative approach to the requiring an
> introduction of delegate interceptors.
> You've mentioned the fact that WSS4JInInterceptor would still need to be
> configured to skip the UT's password validation.
> Your diagram also shows WSS4SecurityProfileEvaluator, which is a delegate
> interceptor.
>
> Honestly, I'm not sure if/when CXF will switch from using WSS4J given that
> existing users already depend on it; may be it is a bit early to start
> thinking of CXF switching from WSS4J just because it enforces the UT
> authentication which can be easily disabled right now.
>
> Thus, perhaps things will get simplified if WSS4JInInterceptor just gets
> optionally injected with say AuthenticationStrategy which will get passed
> WSS4J results (note, the domain will be set as the AuthenticationStrategy
> property) and will return SecurityContext provided the authentication has
> been successful. This can make the security profile block redundant. So
> when
> subclassing becomes too limiting, users would just register a single
> AuthenticationStrategy which can take care of all the understood tokens, as
> opposed to users having to choose between BT, UT, etc interceptors as
> proposed in a diagramm.
> And then, if we have a policy-first case, users will just register
> AuthenticationStrategy as a jaxws property for a given endpoint.
>
> I still may not grasping your idea but just trying to see where/how things
> could get simplified.I think I'd try later on just to write a test which
> would use say a BinaryToken to authenticate a user. And then I may have a
> better/stronger opinion about how things can get improved/simplified.
>
> cheers, Sergey
>
>
> >
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> > Sent: Friday, April 23, 2010 9:16 AM
> > To: dev@cxf.apache.org
> > Subject: Re: Using WS-Security UsernameToken to authenticate users and
> > populate SecurityContexts
> >
> > Hi David
> >
> > I've been thinking a bit more about your idea. As I said it looks
> > interesting but what have not quite understood is how you're planning to
> > hide the WSS4J specifics from the interceptors further in the chain.
> > Example, the Principal that WSS4J UT processor returns has an info about
> > the
> > type of password (digest or not) which is made available to
> > (Abstract)WSS4J(SecurityContext)Interceptor or UsernameTokenInterceptor
> > subclasses without them having to be aware of WSS4J. Both interceptors
> can
> > make the actual Principal available to other interceptors but it is just
> a
> > Principal interface...
> >
> > So I'm presuming, without seeing your diagrams, WSS4JInInterceptor would
> > need to process the WWS4J response and store all the "Credential" objects
> > in
> > a current Message, alongside with properties specifying the types of
> these
> > Credentials. Authenticating interceptors would then check a type, cast a
> > given Credential to say "UTCredential" (with all the details like
> password
> > type, etc) or BinaryTokenCredential, etc... and do whatever they need to.
> > This could indeed present an option to the subclassing one. As I said,
> IMHO
> > the latter one is good enough on its own when we have a UT only to deal
> > with
> > but I'm positive about seeing a more comprehensive approach being
> explored
> > and realized
> >
> > As I said, having some system test (as a patch for ex) would help to see
> > the
> > whole picture you're having in mind.
> >
> > cheers, Sergey
> >
> > On Thu, Apr 22, 2010 at 10:18 PM, Sergey Beryozkin
> > <sb...@gmail.com>wrote:
> >
> > > Hi
> > >
> > > On Thu, Apr 22, 2010 at 9:14 PM, David Valeri <dv...@apache.org>
> > wrote:
> > >
> > >> Attached are some quick and dirty class/seq diagrams that outline a
> > >> slightly
> > >> different approach to determining which credentials to authenticate,
> > >> choosing how to extract them, and then actually performing the
> > >> authentication.
> > >>
> > >>
> > > I do not see the attachments, perhaps you may want to attach them to
> the
> > > actual JIRA
> > > (https://issues.apache.org/jira/browse/CXF-2754)
> > >
> > >
> > >> This approach would still require configuring your customized UT
> > Processor
> > >> in WSS4J in order to disable WSS4Js clumsy authentication system but
> > moves
> > >> the work of creating the SecurityContext and JAAS subject out of the
> > WSS4J
> > >> interceptors and into generic authentication framework. It looks like
> > >> WSS4JInInterceptor simply looks for the first principal it finds in
> the
> > >> WSS4J results and sends that on its way. When multiple tokens appear
> in
> > a
> > >> message, this approach may not always grab the one the application
> > really
> > >> requires.
> > >>
> > >>
> > > OK. I think that for a java-first case utilizing
> > > AbstractSecurityContextProvidingInterceptor
> > > would ensure a Principal associated with a Subject is the one obtained
> > from
> > > a UTProcessor.
> > > Ditto for a policy-first case where a UsernameTakenInterceptor subclass
> > is
> > > used.
> > >
> > >
> > >> This approach works after the WSS4J security processing completes and
> > >> examines the results from WSS4J, or another security framework if we
> > ever
> > >> use one, and determines which profile is in effect. A delegate
> > >> interceptor
> > >> is then called to extract the correct user credentials from the
> message
> > >> and
> > >> perform any additional validation that is needed for a given profile.
> > The
> > >> extracted credentials are then passed to an AuthenticationStrategy to
> > >> perform the actual authentication. The AuthenticationService would
> > return
> > >> something like a JAAS Subject that is then used to create the CXF
> > >> SecurityContext. As you can see, the "Credentials" concept is pretty
> > >> vague
> > >> as there are many different types of credentials out there. I feel
> that
> > >> the
> > >> most common two are X509 certificates and Username Tokens.
> > >>
> > >
> > > Sounds like you're proposing a serious and generic solution which is
> > great.
> > > But I'd be great if you could do a bit of prototyping so that we can
> see
> > > how things (like configuration, etc) actually look like ?
> > > I believe one of your main concerns is that a given request may contain
> > > multiple "Credentials" and thus the approach proposed here
> > > would not necessarily work. Thus seeing a more concrete example could
> > help,
> > > me at least :-)
> > >
> > >
> > >
> > >>
> > >> This approach requires many more classes and could be more complex to
> > >> configure.
> > >
> > >
> > > Well, if it will help addressing some advanced scenarios or make it
> > simpler
> > > to deal with UT/BT/etc in a single uniform way then it would be
> > > justifiable...The thing I like about the approach I've employed for
> > dealing
> > > with UTokens is that it is IMHO very simple and straightforward,
> > especially
> > > in the policy-first case. It is up to the interceptor which creates a
> > > Subject to interact with a 3rd party AuthenticationService (ex,
> something
> > > that has been initially tested with JBoss SecuritySystem), essentially,
> > in
> > > your terms, it is this custom interceptor which acts as an
> > > 'AuthenticationStrategy', every other custom interceptor just
> implements
> > its
> > > own strategy.
> > >
> > > Note, I'm not saying this solution is adequate for all the cases but I
> > > think it works for cases where UTs are involved, possibly encrypted,
> with
> > > plain or digested passwords. But personally I'd also welcome a more
> > thorough
> > > solution/framework and looks like you have all the experience for
> driving
> > it
> > > forward :-). I'm not ready to commit to working on this framework but
> > > depending on how things go and what requirements will be there I may be
> > able
> > > to start contributing and helping with implementing it
> > >
> > >
> > >> I have not thoroughly been over what the default SecurityProfile
> > >> evaluator should be like nor do I know what concrete implementations
> of
> > >> AbstractSecurityContextProvidingInterceptor should be provided. What
> I
> > >> feel
> > >> to be the three most common interceptor instances are listed in the
> > class
> > >> diagram. As for the default SecurityProfileChooser, I initially
> suggest
> > >> that it simply allows the user to enable/disable no security, TLS,
> BST,
> > >> and
> > >> UT while allowing the end user to configure the desired precedence of
> > each
> > >> profile over the other.
> > >>
> > >> This approach can easily work with Spring Security as an
> > >> AuthenticationService implementation.
> > >>
> > >>
> > > sounds great indeed.
> > >
> > > thanks, Sergey
> > >
> > >
> > >> -----Original Message-----
> > >> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> > >> Sent: Wednesday, April 21, 2010 5:47 PM
> > >> To: Daniel Kulp
> > >> Cc: dev@cxf.apache.org
> > >> Subject: Re: Using WS-Security UsernameToken to authenticate users and
> > >> populate SecurityContexts
> > >>
> > >> I added a system test for a policy first case and refactored few bits
> > >> along
> > >> the way, as well as closed [1] as 'Wont fix', at least for now.
> > >>
> > >> I've just updated UsernameTokenInterceptor[1] so that a (WSS4J)
> > principal
> > >> can be created directly if a message property disabling the validation
> > of
> > >> passwords has been set.
> > >>
> > >> This property can be set as a jaxws contextual property in which case
> > >> interceptors further in the chain will be able to get the
> > >> (unauthenticated)
> > >> Principal, validate it, and set a SecurityContext as needed.
> > >>
> > >> Another approach used in the system test is to write a custom
> > >> interceptor[3]
> > >> extending UsernameTokenInterceptor and disable the validation from
> > there.
> > >> This custom interceptor is currently being registered by setting a bus
> > >> property, see [4]. Note that a jaxws endpoint adds
> > >> SimpleAuthorizationInterceptor only and has no callbacks registered.
> > >>
> > >> See [5] for more details.
> > >>
> > >> It looks quite reasonable to me at the moment, perhaps there could be
> a
> > >> simpler way to register custom interceptors.
> > >>
> > >> Dan, you've mentioned the fact you were planning to refactor some of
> the
> > >> policy interceptors so that WSS4JInterceptor is not used for
> > UsernameToken
> > >> processing at all. I'd appreciate if you could look into this
> > refactoring
> > >> yourself, there could be some subtleties there I'm not aware of. Also,
> > >> personally I'd prefer registering a noop processor with WSS4J rather
> > >> adding
> > >> a flag to WSS4J, perhaps this noop processor can be used for handling
> > >> other
> > >> types of tokens, using an approach similar to the one taken by
> > >> UsernameTokenInterceptor, unless yourself, David V, others have
> > something
> > >> else in mind...
> > >>
> > >> cheers, Sergey
> > >>
> > >> [1] https://issues.apache.org/jira/browse/WSS-229
> > >> [2]
> > >>
> > >>
> >
> >
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
> > >> pache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
> > >> [3]
> > >>
> > >>
> >
> >
>
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
> > >>
> >
> >
>
> g/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java<h
> > ttp://
> > svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%
> >
> >
>
> 0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java
> <
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/o
>
> r%%0A0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor
> .java>
> > >
> > >> [4]
> > >>
> > >>
> >
> >
>
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
> > >>
> >
> >
>
> g/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml<http
> > ://
> >
> svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%0Ag
> > /apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml>
> > >> [5] http://svn.apache.org/viewvc?rev=936521&view=rev
> > >>
> > >>
> > >> On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin
> > >> <sb...@gmail.com>wrote:
> > >>
> > >> > Hi
> > >> >
> > >> > I've added an initial patch for addressing a policy-first case, see
> > [1].
> > >> > It's a patch because it depends on another one I submitted to WSS4J
> > [2].
> > >> > Both patches need more work (tests, etc) but I'd just like to
> initiate
> > a
> > >> > discussion/review.
> > >> >
> > >> > The idea behind [1] is quite similar to the one used in supporting a
> > >> > java-first case, where a custom interceptor extends an
> > >> > AbstractWSS4JSecurityContextPr
> > >> > oviding interceptor. But is is much simpler in [1] where
> > >> > UsernameTokenProcessor may be optionally extended and its
> > createSubject
> > >> > method be overridden. Provided [2] gets applied then a subclass will
> > >> just
> > >> > have a property set disabling the (WSS4J) validation of passwords
> and
> > >> will
> > >> > do its own validation in createSubject method.
> > >> >
> > >> > This is really all what will be needed in simple cases, where a
> > >> > DefaultSecurityContext will do, but optionally,
> createSecurityContext
> > >> can
> > >> > be overridden too.
> > >> >
> > >> > A user would need to set a bus property
> > >> > "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a
> > >> custom
> > >> > interceptor which will indicate to the WSSecurityPolicyLoader that a
> > >> custom
> > >> > UsernameTokenProcessor subclass will need to be loaded.
> > >> >
> > >> > Similar approach can be employed for handling other types of tokens.
> > >> >
> > >> > cheers, Sergey
> > >> >
> > >> > [1] https://issues.apache.org/jira/browse/CXF-2754
> > >> > [2] https://issues.apache.org/jira/browse/WSS-229
> > >> >
> > >> >
> > >> > On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin
> > >> <sb...@gmail.com>wrote:
> > >> >
> > >> >> Just realized I did not CC tp dev when replying to Dan the other
> day
> > :
> > >> >>
> > >> >> Hi Dan
> > >> >>
> > >> >>
> > >> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org>
> > wrote:
> > >> >>
> > >> >>>
> > >> >>> My main "concern" with the implementation of this is that it's
> done
> > as
> > >> a
> > >> >>> direct subclass of the WSS4JInInterceptor and thus not really
> usable
> > >> by
> > >> >>> the
> > >> >>> policy based endpoints as those interceptors subclass
> > >> WSS4JInInterceptor
> > >> >>> as
> > >> >>> well.
> > >> >>>
> > >> >>> I think the better approach may be to add a flag to wss4j (I can
> > help
> > >> >>> commit
> > >> >>> changes there if needed) to have it not do any UserName token
> > >> processing
> > >> >>> at
> > >> >>> all. (aside: this may be doable without changes to wss4j by
> > >> >>> registering our
> > >> >>> own "do nothing processor") Then, have another interceptor that
> > >> runs
> > >> >>> after
> > >> >>> the WSS4JInInterceptor that would actually handle the
> UsernameToken
> > >> and
> > >> >>> verify
> > >> >>> anything it needs and such.
> > >> >>>
> > >> >>
> > >> >> This sounds like a very good idea, I agree the proposed approach
> > won't
> > >> do
> > >> >> for the cases where policies drive the
> > >> >> creation of interceptors.
> > >> >>
> > >> >> Having said that, I think the abstract utility interceptor
> extending
> > >> >> WSS4JInInterceptor
> > >> >> may still be used in cases where users start from manually
> > configuring
> > >> >> jaxws endpoints. In these cases they'd need to
> > >> >> list up to 3 interceptors (the one which extends
> > >> >> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor
> > if
> > >> the
> > >> >> authorization is needed plus may be a SAAJ one) but otherwise, when
> > say
> > >> a
> > >> >> clear text password has been encrypted, they'd still need to
> specify
> > >> >> WSS4JInInterceptor (with a flag disabling UsernameToken checks)
> plus
> > >> >> UsernameTokenInterceptor, etc.
> > >> >>
> > >> >> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit
> > >> complicated
> > >> >> due to the fact it blocks the WSS4J digest checks and thus also
> > creates
> > >> a
> > >> >> security engine per every request, but it all will be gone in due
> > >> time...
> > >> >>
> > >> >>
> > >> >>>
> > >> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
> > >> >>> There is
> > >> >>> currently some duplicated code between the
> > >> PolicyBasedWSS4JIinInterceptor
> > >> >>> and
> > >> >>> the new UsernameTokenInterceptor that could be eliminated by
> having
> > >> the
> > >> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
> > >> delegate
> > >> >>> that
> > >> >>> completely to the UsernameTokenInterceptor.
> > >> >>>
> > >> >>
> > >> >> What I will do is I will experiment with the test you added (thanks
> > >> :-))
> > >> >> and see how UsernameTokenInterceptor can be refactored
> > >> >> so that a subclass can get an easy access to password, nonce, etc.
> I
> > >> think
> > >> >> I will need to come up with a contextual property so that a custom
> > >> >> UsernameTokenInterceptor can be installed if needed. Or may be
> > >> >> UsernameTokenInterceptor can store the details in a message to be
> > later
> > >> >> retrieved and processed for creating SecurityContext - but I'm not
> > sure
> > >> >> about it just yet.
> > >> >>
> > >> >>
> > >> >>>
> > >> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
> > >> >>> encryption/signature stuff and then let the authorization
> > validations
> > >> >>> stuff to
> > >> >>> later interceptors. That would include things like key
> validation
> > >> >>> checking
> > >> >>> and stuff as well. Probably SAML token validation as well.
> > >> >>>
> > >> >>>
> > >> >> sounds good
> > >> >>
> > >> >> cheers, Sergey
> > >> >>
> > >> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org>
> > wrote:
> > >> >>
> > >> >>>
> > >> >>> My main "concern" with the implementation of this is that it's
> done
> > as
> > >> a
> > >> >>> direct subclass of the WSS4JInInterceptor and thus not really
> usable
> > >> by
> > >> >>> the
> > >> >>> policy based endpoints as those interceptors subclass
> > >> WSS4JInInterceptor
> > >> >>> as
> > >> >>> well.
> > >> >>>
> > >> >>> I think the better approach may be to add a flag to wss4j (I can
> > help
> > >> >>> commit
> > >> >>> changes there if needed) to have it not do any UserName token
> > >> processing
> > >> >>> at
> > >> >>> all. (aside: this may be doable without changes to wss4j by
> > >> >>> registering our
> > >> >>> own "do nothing processor") Then, have another interceptor that
> > >> runs
> > >> >>> after
> > >> >>> the WSS4JInInterceptor that would actually handle the
> UsernameToken
> > >> and
> > >> >>> verify
> > >> >>> anything it needs and such.
> > >> >>>
> > >> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
> > >> >>> There is
> > >> >>> currently some duplicated code between the
> > >> PolicyBasedWSS4JIinInterceptor
> > >> >>> and
> > >> >>> the new UsernameTokenInterceptor that could be eliminated by
> having
> > >> the
> > >> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
> > >> delegate
> > >> >>> that
> > >> >>> completely to the UsernameTokenInterceptor.
> > >> >>>
> > >> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
> > >> >>> encryption/signature stuff and then let the authorization
> > validations
> > >> >>> stuff to
> > >> >>> later interceptors. That would include things like key
> validation
> > >> >>> checking
> > >> >>> and stuff as well. Probably SAML token validation as well.
> > >> >>>
> > >> >>> Dan
> > >> >>>
> > >> >>>
> > >> >>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
> > >> >>> > Hi David
> > >> >>> >
> > >> >>> > thanks for the comments...
> > >> >>> >
> > >> >>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <
> dvaleri@apache.org>
> > >> >>> wrote:
> > >> >>> > > Sergey,
> > >> >>> > >
> > >> >>> > > I think this type of functionality would be very useful to a
> > >> number
> > >> >>> of
> > >> >>> > > folks. I have built two similar capabilities for clients very
> > >> >>> recently
> > >> >>> > > using CXF and Spring Security. Based on the code provided
> > below,
> > >> I
> > >> >>> have
> > >> >>> > > several points that I would like to see addressed in a
> solution.
> > >> >>> > >
> > >> >>> > > 1) Architecture to support more than just UsernameTokens. I
> > have
> > >> >>> worked
> > >> >>> > > with systems that need to authenticate a user using
> > >> UsernameTokens,
> > >> >>> > > BinarySecurityTokens, SAML Assertions, and a combination of
> more
> > >> than
> > >> >>> one
> > >> >>> > > of
> > >> >>> > > these at a time.
> > >> >>> >
> > >> >>> > Supporting UsernameTokens is the initial requirement. At the
> > moment
> > >> I
> > >> >>> do
> > >> >>> > not even know how BinarySecurityTokens or SAML Assertions are
> > >> >>> > processed/validated in CXF or WSS4J.
> > >> >>> >
> > >> >>> > > For the most part, WSS4J simply validates the structural
> > >> >>> > > details of security. That is, signature validity, trust
> > chaining
> > >> of
> > >> >>> > > digital
> > >> >>> > > certificates, etc. As Glen pointed out with his reference to
> > >> >>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J
> sometimes
> > >> >>> performs
> > >> >>> > > its
> > >> >>> > > own password checking (authentication). Unfortunately, WSS4J
> > >> doesn't
> > >> >>> > > provide hooks for authenticating other forms of credentials
> that
> > I
> > >> >>> have
> > >> >>> > > listed above (I don't consider trust to be equivalent to
> > >> >>> authentication).
> > >> >>> > > It would be best if the authentication interface supported
> > >> multiple
> > >> >>> > > credential types and allowed for authentication to be
> performed
> > in
> > >> a
> > >> >>> > > single location in the same manner every time (not sometimes
> in
> > >> the
> > >> >>> > > WSS4J callback and sometimes in another interceptor for non-UT
> > >> based
> > >> >>> > > credentials).
> > >> >>> >
> > >> >>> > Makes sense. Assuming it is WSS4J which validates (the structure
> > of)
> > >> >>> > BinarySecurityTokens then
> > >> >>> AbstractWSS4JSecurityContextProvidingInterceptor
> > >> >>> > can also implement a processor for BinarySecurityTokens and
> > delegate
> > >> to
> > >> >>> > subclass to authenticate and setup a subject. Some extra methods
> > >> will
> > >> >>> need
> > >> >>> > to be added, to be optionally overridden.
> > >> >>> >
> > >> >>> > If it is not only WSS4J which is involved then perhaps another
> > >> option
> > >> >>> is to
> > >> >>> > store (from WSS4J callback handler, etc) relevant details such
> > >> username
> > >> >>> > token details, etc to be acted upon by other interceptors.
> > >> >>> >
> > >> >>> > > That
> > >> >>> > > last bit there means disabling WSS4J's password authentication
> > >> since
> > >> >>> it
> > >> >>> > > gets
> > >> >>> > > in the way of doing it later in our own interceptor.
> > >> >>> >
> > >> >>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
> > >> >>> > implementing a simplified UsernameTokenProcessor
> > >> >>> >
> > >> >>> > > 2) Allow for end-user flexibility in choosing the credentials
> > they
> > >> >>> want
> > >> >>> > > to authenticate. For instance, each user is going to have
> their
> > >> own
> > >> >>> > > security profiles and authentication requirements. For
> > instance,
> > >> a
> > >> >>> > > message contains a UT for a portal user and a digital
> signature
> > >> from
> > >> >>> the
> > >> >>> > > portal (I know using
> > >> >>> > > a SAML Assertion would be better here, but people still do it
> > this
> > >> >>> way).
> > >> >>> > > Each organization will have different requirements as to which
> > >> >>> > > credentials get authenticated and what needs to end up in the
> > >> >>> security
> > >> >>> > > context.
> > >> >>> >
> > >> >>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor
> > >> subclasses
> > >> >>> > should be able to do it, for username tokens and other tokens
> > later
> > >> on.
> > >> >>> >
> > >> >>> > > 3) Decouple the authentication interface from WSS4J. What is
> > >> passed
> > >> >>> in
> > >> >>> > > needs to be abstracted enough that it can work with other
> > >> WS-Security
> > >> >>> > > libraries as well.
> > >> >>> >
> > >> >>> > the only WSS4J class which is leaked at the moment is
> > >> >>> WSSecurityException.
> > >> >>> > Perhaps we can come up later on with a different more generic
> > >> approach
> > >> >>> > which does not depend on WSS4J at all. As Dan indicated, in some
> > >> cases
> > >> >>> > WSS4JInInterceptor is not even used, so that case will need to
> be
> > >> >>> > addressed. Experimenting wuth binary tokens might help with
> > >> identifying
> > >> >>> > another solution.
> > >> >>> >
> > >> >>> > > 4) It would be nice to be able to perform authorization using
> > >> >>> something
> > >> >>> > > like
> > >> >>> > > Spring Security at the service operation level. With a POJO
> or
> > >> >>> JAX-WS
> > >> >>> > > based
> > >> >>> > > service, one can just use Spring Security's method interceptor
> > to
> > >> >>> provide
> > >> >>> > > such security; however, in situations where one only has a
> WSDL
> > >> based
> > >> >>> > > service or a provider style service, a method interceptor
> can't
> > be
> > >> >>> used.
> > >> >>> > >
> > >> >>> > > It
> > >> >>> > >
> > >> >>> > > would be nice to provide a hook into Spring Security to allow
> > >> >>> end-users
> > >> >>> > > to specify role based authorization policy based on a
> > combination
> > >> of
> > >> >>> > > interface,
> > >> >>> > > instance, and operation names. It seems like your
> > >> >>> > > AbstractAuthorizingInterceptor and
> SimpleAuthorizingInterceptor
> > >> are
> > >> >>> > > looking in this direction, but I think it would be best if we
> > can
> > >> >>> stand
> > >> >>> > > on the shoulders of the Spring Security giant as much as
> > possible
> > >> so
> > >> >>> > > that we can take advantage of their rich authorization
> manager,
> > >> >>> voter,
> > >> >>> > > XML
> > >> >>> > > configuration
> > >> >>> > > capabilities.
> > >> >>> >
> > >> >>> > Not sure what to say here yet. But I think non-Spring users
> should
> > >> be
> > >> >>> taken
> > >> >>> > care of too. Or when simpler cases are dealt with then perhaps
> > >> there's
> > >> >>> no
> > >> >>> > need to bring in Spring security. Perhaps the utility
> > authorization
> > >> >>> > interceptors should just not be used when Spring Security is
> > >> preferred
> > >> >>> ?
> > >> >>> >
> > >> >>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold.
> The
> > >> >>> CXF-BC
> > >> >>> > > currently has a limited capability to select the credentials
> to
> > >> >>> > > authenticate
> > >> >>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
> > >> >>> delegates
> > >> >>> > > authentication to the JBI container through a ServiceMix
> > >> components
> > >> >>> > > authentication service abstraction of JAAS. Whatever solution
> > we
> > >> >>> have
> > >> >>> > > for 1
> > >> >>> > > and 2 would help out the component if the ServiceMix
> > >> authentication
> > >> >>> > > service abstraction could be wired up in lieu of whatever we
> > >> provide
> > >> >>> out
> > >> >>> > > of the box.
> > >> >>> >
> > >> >>> > I'm not planning to contribute to ServiceMix. I agree though
> that
> > an
> > >> >>> ideal
> > >> >>> > solution will meet multiple requirements
> > >> >>> >
> > >> >>> > thanks, Sergey
> > >> >>> >
> > >> >>> > > -----Original Message-----
> > >> >>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> > >> >>> > > Sent: Wednesday, April 07, 2010 10:11 AM
> > >> >>> > > To: dev@cxf.apache.org
> > >> >>> > > Subject: Using WS-Security UsernameToken to authenticate users
> > and
> > >> >>> > > populate SecurityContexts
> > >> >>> > >
> > >> >>> > > Hi
> > >> >>> > >
> > >> >>> > > I've been looking recently at extending the CXF WS-Security
> > >> component
> > >> >>> > > such that a current UsernameToken could be used by custom
> > >> >>> interceptors
> > >> >>> > > to authenticate a user with the external security systems and,
> > if
> > >> >>> > > possible, provide enough information for CXF to populate a
> > >> >>> > > SecurityContext [1] to be used later on for
> > >> >>> > > authorization decisions.
> > >> >>> > >
> > >> >>> > > Here is the approach I've taken so far.
> > >> >>> > > A custom interceptor extends
> > >> >>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the
> > only
> > >> >>> method
> > >> >>> > > it overrides is
> > >> >>> > >
> > >> >>> > > abstract Subject createSubject(String name, String password,
> > >> boolean
> > >> >>> > > isDigest,
> > >> >>> > >
> > >> >>> > > String nonce,
> > >> >>> > > String created) throws
> > >> >>> > >
> > >> >>> > > WSSecurityException;
> > >> >>> > >
> > >> >>> > >
> > >> >>> > > For example, see [3].
> > >> >>> > >
> > >> >>> > > The idea here is that a custom interceptor interfaces
> whichever
> > >> way
> > >> >>> it
> > >> >>> > > needs
> > >> >>> > > to with the external system and populates a Subject following
> > this
> > >> >>> simple
> > >> >>> > > rule : first Subject principal is the current user (identified
> > by
> > >> a
> > >> >>> > > 'name' argument), followed by one or more Groups this user is
> a
> > >> >>> member
> > >> >>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use
> > this
> > >> >>> > > Subject to provide a functional SecurityContext instance.
> > >> >>> > >
> > >> >>> > > This is the first part, next is how to utilize a
> SecurityContext
> > >> and
> > >> >>> get
> > >> >>> > > the
> > >> >>> > > expected roles associated one way or the other with a current
> > >> method
> > >> >>> to
> > >> >>> > > be invoked. There's a number of usual options available here,
> > >> perhaps
> > >> >>> > > even SpringSecurity can be used now that SecurityContext is
> > >> >>> available,
> > >> >>> > > or application code or other custom CXF interceptor can check
> > the
> > >> >>> known
> > >> >>> > > roles against SecurityContext.
> > >> >>> > >
> > >> >>> > > I've also added AbstractAuthorizingInInterceptor interceptor
> > which
> > >> >>> custom
> > >> >>> > > interceptors can override and return a list of expected roles
> > >> given
> > >> a
> > >> >>> > > (service) Method to be invoked upon,
> > >> AbstractAuthorizingInInterceptor
> > >> >>> > > will then ask available SecurityContext to match the roles;
> one
> > >> >>> concrete
> > >> >>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
> > >> injected
> > >> >>> > > with a
> > >> >>> > > method specific or class (applying to all methods) roles.
> > Another
> > >> >>> > > implementation which I will likely add later on will be
> injected
> > >> with
> > >> >>> a
> > >> >>> > > name
> > >> >>> > > of annotation such as RolesAlloved and it will introspect a
> > method
> > >> >>> and
> > >> >>> > > its class.
> > >> >>> > >
> > >> >>> > > Note that I haven't looked into the case when a policy
> runtimes
> > >> adds
> > >> >>> the
> > >> >>> > > interceptors yet (as opposed to interceptors being configured
> > form
> > >> >>> > > Spring/programmatically). I think an optional contextual
> > property
> > >> >>> will
> > >> >>> > > need to be setup in such cases for users be able to indicate
> > that
> > >> say
> > >> >>> an
> > >> >>> > > interceptor such as [3] has to be used as opposed to
> > >> >>> WSS4JInInterceptor,
> > >> >>> > > etc.
> > >> >>> > >
> > >> >>> > > I'm going to validate this approach with JBoss CXF. If you
> have
> > >> any
> > >> >>> > > comments
> > >> >>> > > then please let me know.
> > >> >>> > >
> > >> >>> > > I think we may have a simpler alternative eventually to the
> way
> > >> >>> > > authorization decisions are made. [1]-[3] is specific to
> > >> ws-security,
> > >> >>> but
> > >> >>> > > [4]-[5] is not
> > >> >>> > >
> > >> >>> > > cheers, Sergey
> > >> >>> > >
> > >> >>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
> > >> >>> > > [2]
> > >> >>> > >
> > >> >>> > >
> > >> >>>
> > >>
> >
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
> > >> >>> > > g/a
> > >> >>> > >
> > >> >>> > >
> > >> >>>
> > >>
> > pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
> > >> >>> > > tor<
> > >> >>>
> > http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
> > >> >>> > >
> > >> >>>
> > >>
> > a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
> > >> >>> > > ngInterceptor> .java
> > >> >>> > > [3]
> > >> >>> > >
> > >> >>> > >
> > >> >>>
> > >>
> >
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
> > >> >>> > > g/a
> > >> >>> > >
> > >> >>>
> > >>
> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
> > >> >>> > > /
> > >> >>>
> > >>
> > svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
> > >> >>> > >
> > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
> > >> >>> [4]
> > >> >>> > >
> > >> >>> > >
> > >> >>>
> > >>
> >
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> > >> >>> > > e/c
> > >> >>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
> > >> >>> http://svn
> > >> >>> > > .
> > >> >>>
> > >>
> > apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
> > >> >>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
> > >> >>> > >
> > >> >>> > >
> > >> >>>
> > >>
> >
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> > >> >>> > > e/c
> > >> >>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
> > >> >>> http://svn.apa
> > >> >>> > >
> > >> >>>
> > >>
> >
> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
> > >> >>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
> > >> >>>
> > >> >>> --
> > >> >>> Daniel Kulp
> > >> >>> dkulp@apache.org
> > >> >>> http://dankulp.com/blog
> > >> >>>
> > >> >>
> > >> >>
> > >> >
> > >>
> > >
> > >
> >
> >
>
>
RE: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Posted by David Valeri <dv...@apache.org>.
Good points.
I think we could combine some of the things that my
AbstractSecurityContextProvidingInterceptor does into the existing
WSS4JInInterceptor and also hand it an AuthenticationStrategy. Where I
think additional classes are still needed is with the concrete
implementations of my AbstractSecurityContextProvidingInterceptor and the
SecurityProfileEvaluator. I believe that we want a loose coupling between
the Interceptors, whatever XML/WS security library we use and the
AuthenticationStrategy. Here are the reasons in support of the capabilities
I propose (although maybe not in the form of the initial class diagram):
1) SecurityProfileEvaluator. The simple case is when you have just a UT or
BST. In this case, we just want to pull the only credentials or principal
from the WSS4J results and work with that. But what about the brokered
identity case where a portal or client-app signs the message using a BST,
but has put a UT in the header that represents the human user. Same goes
for when there is a signature created with a BST, but the authentication
information is being conveyed through a SAML assertion. WSS4J just
validates the syntactical parts of the message. It does not understand
which tokens in the message (UT, BST, SAML, etc) represent the end user,
intermediaries, etc. The evaluator lets the end users have a pluggable
strategy for determining the active security profile based on message
contents. I have had clients who may support more than one profile
concurrently, so they ability to determine the active profile from one of
many possibilities is relevant to them.
2) The concrete implementations of
AbstractSecurityContextProvidingInterceptor. These classes know what to
extract from the message and actually pass to the authentication service.
For a BST, trust, expiration, and revocation have all previously been
confirmed (at least they should have been) by other means. All that is left
is to map the BST's digital certificate to a set of authentication details
in a user repository. For UTs, you first confirm the password, then map the
username to a set of authentication details.
3) Loose coupling to AuthenticationStrategy. We have no idea what types of
tokens end users will be using. I have identified some of the most common,
but in reality, the possibilities are endless. Whatever our abstraction
over the actual authentication mechanism looks like, I don't think it should
take arguments such as username and password. I also don't think that it
should take anything specifically from WSS4J such as a WSS4J provided
Principal implementation.
After thinking about your feedback, I am thinking that having two separate
class hierarchies to figure all of this out may be too complex. Perhaps
something more like a JAAS configuration where you can order the
LoginModules and declare each module's needed level of participation is more
appropriate. In this way, we would have self contained profile support
classes that can both detect if the profile they support is active and
extract the appropriate credentials and attempt authentication. The CXF
Interceptor could function more like a JAAS LoginContext by orchestrating
the execution of the profile support classes and putting the results into
the CXF message context.
I'll think about this some more and try to provide some updated diagrams to
help convey my thoughts.
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Friday, April 23, 2010 1:03 PM
To: dev@cxf.apache.org
Subject: Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
On Fri, Apr 23, 2010 at 2:53 PM, David Valeri <dv...@apache.org> wrote:
> I have attached the diagrams to the ticket in JIRA.
>
thanks...
>
> The eventual interceptor that handles a profile would be specific to the
> security implementation used as it ultimately needs to look at results
that
> are in a proprietary form (WSS4J, METRO, etc.). What the framework
> provides
> is some scaffolding to handle the boilerplate stuff such that concrete
> interceptors only have to deal with extracting credentials and it allows
> end
> users to substitute their own interceptor implementations for whatever
> profiles they need to support.
>
Now, here is a slightly alternative approach to the requiring an
introduction of delegate interceptors.
You've mentioned the fact that WSS4JInInterceptor would still need to be
configured to skip the UT's password validation.
Your diagram also shows WSS4SecurityProfileEvaluator, which is a delegate
interceptor.
Honestly, I'm not sure if/when CXF will switch from using WSS4J given that
existing users already depend on it; may be it is a bit early to start
thinking of CXF switching from WSS4J just because it enforces the UT
authentication which can be easily disabled right now.
Thus, perhaps things will get simplified if WSS4JInInterceptor just gets
optionally injected with say AuthenticationStrategy which will get passed
WSS4J results (note, the domain will be set as the AuthenticationStrategy
property) and will return SecurityContext provided the authentication has
been successful. This can make the security profile block redundant. So when
subclassing becomes too limiting, users would just register a single
AuthenticationStrategy which can take care of all the understood tokens, as
opposed to users having to choose between BT, UT, etc interceptors as
proposed in a diagramm.
And then, if we have a policy-first case, users will just register
AuthenticationStrategy as a jaxws property for a given endpoint.
I still may not grasping your idea but just trying to see where/how things
could get simplified.I think I'd try later on just to write a test which
would use say a BinaryToken to authenticate a user. And then I may have a
better/stronger opinion about how things can get improved/simplified.
cheers, Sergey
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Friday, April 23, 2010 9:16 AM
> To: dev@cxf.apache.org
> Subject: Re: Using WS-Security UsernameToken to authenticate users and
> populate SecurityContexts
>
> Hi David
>
> I've been thinking a bit more about your idea. As I said it looks
> interesting but what have not quite understood is how you're planning to
> hide the WSS4J specifics from the interceptors further in the chain.
> Example, the Principal that WSS4J UT processor returns has an info about
> the
> type of password (digest or not) which is made available to
> (Abstract)WSS4J(SecurityContext)Interceptor or UsernameTokenInterceptor
> subclasses without them having to be aware of WSS4J. Both interceptors can
> make the actual Principal available to other interceptors but it is just a
> Principal interface...
>
> So I'm presuming, without seeing your diagrams, WSS4JInInterceptor would
> need to process the WWS4J response and store all the "Credential" objects
> in
> a current Message, alongside with properties specifying the types of these
> Credentials. Authenticating interceptors would then check a type, cast a
> given Credential to say "UTCredential" (with all the details like password
> type, etc) or BinaryTokenCredential, etc... and do whatever they need to.
> This could indeed present an option to the subclassing one. As I said,
IMHO
> the latter one is good enough on its own when we have a UT only to deal
> with
> but I'm positive about seeing a more comprehensive approach being explored
> and realized
>
> As I said, having some system test (as a patch for ex) would help to see
> the
> whole picture you're having in mind.
>
> cheers, Sergey
>
> On Thu, Apr 22, 2010 at 10:18 PM, Sergey Beryozkin
> <sb...@gmail.com>wrote:
>
> > Hi
> >
> > On Thu, Apr 22, 2010 at 9:14 PM, David Valeri <dv...@apache.org>
> wrote:
> >
> >> Attached are some quick and dirty class/seq diagrams that outline a
> >> slightly
> >> different approach to determining which credentials to authenticate,
> >> choosing how to extract them, and then actually performing the
> >> authentication.
> >>
> >>
> > I do not see the attachments, perhaps you may want to attach them to the
> > actual JIRA
> > (https://issues.apache.org/jira/browse/CXF-2754)
> >
> >
> >> This approach would still require configuring your customized UT
> Processor
> >> in WSS4J in order to disable WSS4Js clumsy authentication system but
> moves
> >> the work of creating the SecurityContext and JAAS subject out of the
> WSS4J
> >> interceptors and into generic authentication framework. It looks like
> >> WSS4JInInterceptor simply looks for the first principal it finds in the
> >> WSS4J results and sends that on its way. When multiple tokens appear
in
> a
> >> message, this approach may not always grab the one the application
> really
> >> requires.
> >>
> >>
> > OK. I think that for a java-first case utilizing
> > AbstractSecurityContextProvidingInterceptor
> > would ensure a Principal associated with a Subject is the one obtained
> from
> > a UTProcessor.
> > Ditto for a policy-first case where a UsernameTakenInterceptor subclass
> is
> > used.
> >
> >
> >> This approach works after the WSS4J security processing completes and
> >> examines the results from WSS4J, or another security framework if we
> ever
> >> use one, and determines which profile is in effect. A delegate
> >> interceptor
> >> is then called to extract the correct user credentials from the message
> >> and
> >> perform any additional validation that is needed for a given profile.
> The
> >> extracted credentials are then passed to an AuthenticationStrategy to
> >> perform the actual authentication. The AuthenticationService would
> return
> >> something like a JAAS Subject that is then used to create the CXF
> >> SecurityContext. As you can see, the "Credentials" concept is pretty
> >> vague
> >> as there are many different types of credentials out there. I feel
that
> >> the
> >> most common two are X509 certificates and Username Tokens.
> >>
> >
> > Sounds like you're proposing a serious and generic solution which is
> great.
> > But I'd be great if you could do a bit of prototyping so that we can see
> > how things (like configuration, etc) actually look like ?
> > I believe one of your main concerns is that a given request may contain
> > multiple "Credentials" and thus the approach proposed here
> > would not necessarily work. Thus seeing a more concrete example could
> help,
> > me at least :-)
> >
> >
> >
> >>
> >> This approach requires many more classes and could be more complex to
> >> configure.
> >
> >
> > Well, if it will help addressing some advanced scenarios or make it
> simpler
> > to deal with UT/BT/etc in a single uniform way then it would be
> > justifiable...The thing I like about the approach I've employed for
> dealing
> > with UTokens is that it is IMHO very simple and straightforward,
> especially
> > in the policy-first case. It is up to the interceptor which creates a
> > Subject to interact with a 3rd party AuthenticationService (ex,
something
> > that has been initially tested with JBoss SecuritySystem), essentially,
> in
> > your terms, it is this custom interceptor which acts as an
> > 'AuthenticationStrategy', every other custom interceptor just implements
> its
> > own strategy.
> >
> > Note, I'm not saying this solution is adequate for all the cases but I
> > think it works for cases where UTs are involved, possibly encrypted,
with
> > plain or digested passwords. But personally I'd also welcome a more
> thorough
> > solution/framework and looks like you have all the experience for
driving
> it
> > forward :-). I'm not ready to commit to working on this framework but
> > depending on how things go and what requirements will be there I may be
> able
> > to start contributing and helping with implementing it
> >
> >
> >> I have not thoroughly been over what the default SecurityProfile
> >> evaluator should be like nor do I know what concrete implementations of
> >> AbstractSecurityContextProvidingInterceptor should be provided. What I
> >> feel
> >> to be the three most common interceptor instances are listed in the
> class
> >> diagram. As for the default SecurityProfileChooser, I initially
suggest
> >> that it simply allows the user to enable/disable no security, TLS, BST,
> >> and
> >> UT while allowing the end user to configure the desired precedence of
> each
> >> profile over the other.
> >>
> >> This approach can easily work with Spring Security as an
> >> AuthenticationService implementation.
> >>
> >>
> > sounds great indeed.
> >
> > thanks, Sergey
> >
> >
> >> -----Original Message-----
> >> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >> Sent: Wednesday, April 21, 2010 5:47 PM
> >> To: Daniel Kulp
> >> Cc: dev@cxf.apache.org
> >> Subject: Re: Using WS-Security UsernameToken to authenticate users and
> >> populate SecurityContexts
> >>
> >> I added a system test for a policy first case and refactored few bits
> >> along
> >> the way, as well as closed [1] as 'Wont fix', at least for now.
> >>
> >> I've just updated UsernameTokenInterceptor[1] so that a (WSS4J)
> principal
> >> can be created directly if a message property disabling the validation
> of
> >> passwords has been set.
> >>
> >> This property can be set as a jaxws contextual property in which case
> >> interceptors further in the chain will be able to get the
> >> (unauthenticated)
> >> Principal, validate it, and set a SecurityContext as needed.
> >>
> >> Another approach used in the system test is to write a custom
> >> interceptor[3]
> >> extending UsernameTokenInterceptor and disable the validation from
> there.
> >> This custom interceptor is currently being registered by setting a bus
> >> property, see [4]. Note that a jaxws endpoint adds
> >> SimpleAuthorizationInterceptor only and has no callbacks registered.
> >>
> >> See [5] for more details.
> >>
> >> It looks quite reasonable to me at the moment, perhaps there could be a
> >> simpler way to register custom interceptors.
> >>
> >> Dan, you've mentioned the fact you were planning to refactor some of
the
> >> policy interceptors so that WSS4JInterceptor is not used for
> UsernameToken
> >> processing at all. I'd appreciate if you could look into this
> refactoring
> >> yourself, there could be some subtleties there I'm not aware of. Also,
> >> personally I'd prefer registering a noop processor with WSS4J rather
> >> adding
> >> a flag to WSS4J, perhaps this noop processor can be used for handling
> >> other
> >> types of tokens, using an approach similar to the one taken by
> >> UsernameTokenInterceptor, unless yourself, David V, others have
> something
> >> else in mind...
> >>
> >> cheers, Sergey
> >>
> >> [1] https://issues.apache.org/jira/browse/WSS-229
> >> [2]
> >>
> >>
>
>
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
> >> pache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
> >> [3]
> >>
> >>
>
>
http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
> >>
>
>
g/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java<h
> ttp://
> svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%
>
>
0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java
<http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/o
r%%0A0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor
.java>
> >
> >> [4]
> >>
> >>
>
>
http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
> >>
>
>
g/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml<http
> ://
> svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%0Ag
> /apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml>
> >> [5] http://svn.apache.org/viewvc?rev=936521&view=rev
> >>
> >>
> >> On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin
> >> <sb...@gmail.com>wrote:
> >>
> >> > Hi
> >> >
> >> > I've added an initial patch for addressing a policy-first case, see
> [1].
> >> > It's a patch because it depends on another one I submitted to WSS4J
> [2].
> >> > Both patches need more work (tests, etc) but I'd just like to
initiate
> a
> >> > discussion/review.
> >> >
> >> > The idea behind [1] is quite similar to the one used in supporting a
> >> > java-first case, where a custom interceptor extends an
> >> > AbstractWSS4JSecurityContextPr
> >> > oviding interceptor. But is is much simpler in [1] where
> >> > UsernameTokenProcessor may be optionally extended and its
> createSubject
> >> > method be overridden. Provided [2] gets applied then a subclass will
> >> just
> >> > have a property set disabling the (WSS4J) validation of passwords and
> >> will
> >> > do its own validation in createSubject method.
> >> >
> >> > This is really all what will be needed in simple cases, where a
> >> > DefaultSecurityContext will do, but optionally, createSecurityContext
> >> can
> >> > be overridden too.
> >> >
> >> > A user would need to set a bus property
> >> > "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a
> >> custom
> >> > interceptor which will indicate to the WSSecurityPolicyLoader that a
> >> custom
> >> > UsernameTokenProcessor subclass will need to be loaded.
> >> >
> >> > Similar approach can be employed for handling other types of tokens.
> >> >
> >> > cheers, Sergey
> >> >
> >> > [1] https://issues.apache.org/jira/browse/CXF-2754
> >> > [2] https://issues.apache.org/jira/browse/WSS-229
> >> >
> >> >
> >> > On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin
> >> <sb...@gmail.com>wrote:
> >> >
> >> >> Just realized I did not CC tp dev when replying to Dan the other day
> :
> >> >>
> >> >> Hi Dan
> >> >>
> >> >>
> >> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org>
> wrote:
> >> >>
> >> >>>
> >> >>> My main "concern" with the implementation of this is that it's done
> as
> >> a
> >> >>> direct subclass of the WSS4JInInterceptor and thus not really
usable
> >> by
> >> >>> the
> >> >>> policy based endpoints as those interceptors subclass
> >> WSS4JInInterceptor
> >> >>> as
> >> >>> well.
> >> >>>
> >> >>> I think the better approach may be to add a flag to wss4j (I can
> help
> >> >>> commit
> >> >>> changes there if needed) to have it not do any UserName token
> >> processing
> >> >>> at
> >> >>> all. (aside: this may be doable without changes to wss4j by
> >> >>> registering our
> >> >>> own "do nothing processor") Then, have another interceptor that
> >> runs
> >> >>> after
> >> >>> the WSS4JInInterceptor that would actually handle the UsernameToken
> >> and
> >> >>> verify
> >> >>> anything it needs and such.
> >> >>>
> >> >>
> >> >> This sounds like a very good idea, I agree the proposed approach
> won't
> >> do
> >> >> for the cases where policies drive the
> >> >> creation of interceptors.
> >> >>
> >> >> Having said that, I think the abstract utility interceptor extending
> >> >> WSS4JInInterceptor
> >> >> may still be used in cases where users start from manually
> configuring
> >> >> jaxws endpoints. In these cases they'd need to
> >> >> list up to 3 interceptors (the one which extends
> >> >> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor
> if
> >> the
> >> >> authorization is needed plus may be a SAAJ one) but otherwise, when
> say
> >> a
> >> >> clear text password has been encrypted, they'd still need to specify
> >> >> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
> >> >> UsernameTokenInterceptor, etc.
> >> >>
> >> >> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit
> >> complicated
> >> >> due to the fact it blocks the WSS4J digest checks and thus also
> creates
> >> a
> >> >> security engine per every request, but it all will be gone in due
> >> time...
> >> >>
> >> >>
> >> >>>
> >> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
> >> >>> There is
> >> >>> currently some duplicated code between the
> >> PolicyBasedWSS4JIinInterceptor
> >> >>> and
> >> >>> the new UsernameTokenInterceptor that could be eliminated by having
> >> the
> >> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
> >> delegate
> >> >>> that
> >> >>> completely to the UsernameTokenInterceptor.
> >> >>>
> >> >>
> >> >> What I will do is I will experiment with the test you added (thanks
> >> :-))
> >> >> and see how UsernameTokenInterceptor can be refactored
> >> >> so that a subclass can get an easy access to password, nonce, etc. I
> >> think
> >> >> I will need to come up with a contextual property so that a custom
> >> >> UsernameTokenInterceptor can be installed if needed. Or may be
> >> >> UsernameTokenInterceptor can store the details in a message to be
> later
> >> >> retrieved and processed for creating SecurityContext - but I'm not
> sure
> >> >> about it just yet.
> >> >>
> >> >>
> >> >>>
> >> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
> >> >>> encryption/signature stuff and then let the authorization
> validations
> >> >>> stuff to
> >> >>> later interceptors. That would include things like key validation
> >> >>> checking
> >> >>> and stuff as well. Probably SAML token validation as well.
> >> >>>
> >> >>>
> >> >> sounds good
> >> >>
> >> >> cheers, Sergey
> >> >>
> >> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org>
> wrote:
> >> >>
> >> >>>
> >> >>> My main "concern" with the implementation of this is that it's done
> as
> >> a
> >> >>> direct subclass of the WSS4JInInterceptor and thus not really
usable
> >> by
> >> >>> the
> >> >>> policy based endpoints as those interceptors subclass
> >> WSS4JInInterceptor
> >> >>> as
> >> >>> well.
> >> >>>
> >> >>> I think the better approach may be to add a flag to wss4j (I can
> help
> >> >>> commit
> >> >>> changes there if needed) to have it not do any UserName token
> >> processing
> >> >>> at
> >> >>> all. (aside: this may be doable without changes to wss4j by
> >> >>> registering our
> >> >>> own "do nothing processor") Then, have another interceptor that
> >> runs
> >> >>> after
> >> >>> the WSS4JInInterceptor that would actually handle the UsernameToken
> >> and
> >> >>> verify
> >> >>> anything it needs and such.
> >> >>>
> >> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
> >> >>> There is
> >> >>> currently some duplicated code between the
> >> PolicyBasedWSS4JIinInterceptor
> >> >>> and
> >> >>> the new UsernameTokenInterceptor that could be eliminated by having
> >> the
> >> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
> >> delegate
> >> >>> that
> >> >>> completely to the UsernameTokenInterceptor.
> >> >>>
> >> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
> >> >>> encryption/signature stuff and then let the authorization
> validations
> >> >>> stuff to
> >> >>> later interceptors. That would include things like key validation
> >> >>> checking
> >> >>> and stuff as well. Probably SAML token validation as well.
> >> >>>
> >> >>> Dan
> >> >>>
> >> >>>
> >> >>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
> >> >>> > Hi David
> >> >>> >
> >> >>> > thanks for the comments...
> >> >>> >
> >> >>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
> >> >>> wrote:
> >> >>> > > Sergey,
> >> >>> > >
> >> >>> > > I think this type of functionality would be very useful to a
> >> number
> >> >>> of
> >> >>> > > folks. I have built two similar capabilities for clients very
> >> >>> recently
> >> >>> > > using CXF and Spring Security. Based on the code provided
> below,
> >> I
> >> >>> have
> >> >>> > > several points that I would like to see addressed in a
solution.
> >> >>> > >
> >> >>> > > 1) Architecture to support more than just UsernameTokens. I
> have
> >> >>> worked
> >> >>> > > with systems that need to authenticate a user using
> >> UsernameTokens,
> >> >>> > > BinarySecurityTokens, SAML Assertions, and a combination of
more
> >> than
> >> >>> one
> >> >>> > > of
> >> >>> > > these at a time.
> >> >>> >
> >> >>> > Supporting UsernameTokens is the initial requirement. At the
> moment
> >> I
> >> >>> do
> >> >>> > not even know how BinarySecurityTokens or SAML Assertions are
> >> >>> > processed/validated in CXF or WSS4J.
> >> >>> >
> >> >>> > > For the most part, WSS4J simply validates the structural
> >> >>> > > details of security. That is, signature validity, trust
> chaining
> >> of
> >> >>> > > digital
> >> >>> > > certificates, etc. As Glen pointed out with his reference to
> >> >>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
> >> >>> performs
> >> >>> > > its
> >> >>> > > own password checking (authentication). Unfortunately, WSS4J
> >> doesn't
> >> >>> > > provide hooks for authenticating other forms of credentials
that
> I
> >> >>> have
> >> >>> > > listed above (I don't consider trust to be equivalent to
> >> >>> authentication).
> >> >>> > > It would be best if the authentication interface supported
> >> multiple
> >> >>> > > credential types and allowed for authentication to be performed
> in
> >> a
> >> >>> > > single location in the same manner every time (not sometimes in
> >> the
> >> >>> > > WSS4J callback and sometimes in another interceptor for non-UT
> >> based
> >> >>> > > credentials).
> >> >>> >
> >> >>> > Makes sense. Assuming it is WSS4J which validates (the structure
> of)
> >> >>> > BinarySecurityTokens then
> >> >>> AbstractWSS4JSecurityContextProvidingInterceptor
> >> >>> > can also implement a processor for BinarySecurityTokens and
> delegate
> >> to
> >> >>> > subclass to authenticate and setup a subject. Some extra methods
> >> will
> >> >>> need
> >> >>> > to be added, to be optionally overridden.
> >> >>> >
> >> >>> > If it is not only WSS4J which is involved then perhaps another
> >> option
> >> >>> is to
> >> >>> > store (from WSS4J callback handler, etc) relevant details such
> >> username
> >> >>> > token details, etc to be acted upon by other interceptors.
> >> >>> >
> >> >>> > > That
> >> >>> > > last bit there means disabling WSS4J's password authentication
> >> since
> >> >>> it
> >> >>> > > gets
> >> >>> > > in the way of doing it later in our own interceptor.
> >> >>> >
> >> >>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
> >> >>> > implementing a simplified UsernameTokenProcessor
> >> >>> >
> >> >>> > > 2) Allow for end-user flexibility in choosing the credentials
> they
> >> >>> want
> >> >>> > > to authenticate. For instance, each user is going to have
their
> >> own
> >> >>> > > security profiles and authentication requirements. For
> instance,
> >> a
> >> >>> > > message contains a UT for a portal user and a digital signature
> >> from
> >> >>> the
> >> >>> > > portal (I know using
> >> >>> > > a SAML Assertion would be better here, but people still do it
> this
> >> >>> way).
> >> >>> > > Each organization will have different requirements as to which
> >> >>> > > credentials get authenticated and what needs to end up in the
> >> >>> security
> >> >>> > > context.
> >> >>> >
> >> >>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor
> >> subclasses
> >> >>> > should be able to do it, for username tokens and other tokens
> later
> >> on.
> >> >>> >
> >> >>> > > 3) Decouple the authentication interface from WSS4J. What is
> >> passed
> >> >>> in
> >> >>> > > needs to be abstracted enough that it can work with other
> >> WS-Security
> >> >>> > > libraries as well.
> >> >>> >
> >> >>> > the only WSS4J class which is leaked at the moment is
> >> >>> WSSecurityException.
> >> >>> > Perhaps we can come up later on with a different more generic
> >> approach
> >> >>> > which does not depend on WSS4J at all. As Dan indicated, in some
> >> cases
> >> >>> > WSS4JInInterceptor is not even used, so that case will need to be
> >> >>> > addressed. Experimenting wuth binary tokens might help with
> >> identifying
> >> >>> > another solution.
> >> >>> >
> >> >>> > > 4) It would be nice to be able to perform authorization using
> >> >>> something
> >> >>> > > like
> >> >>> > > Spring Security at the service operation level. With a POJO or
> >> >>> JAX-WS
> >> >>> > > based
> >> >>> > > service, one can just use Spring Security's method interceptor
> to
> >> >>> provide
> >> >>> > > such security; however, in situations where one only has a WSDL
> >> based
> >> >>> > > service or a provider style service, a method interceptor can't
> be
> >> >>> used.
> >> >>> > >
> >> >>> > > It
> >> >>> > >
> >> >>> > > would be nice to provide a hook into Spring Security to allow
> >> >>> end-users
> >> >>> > > to specify role based authorization policy based on a
> combination
> >> of
> >> >>> > > interface,
> >> >>> > > instance, and operation names. It seems like your
> >> >>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor
> >> are
> >> >>> > > looking in this direction, but I think it would be best if we
> can
> >> >>> stand
> >> >>> > > on the shoulders of the Spring Security giant as much as
> possible
> >> so
> >> >>> > > that we can take advantage of their rich authorization manager,
> >> >>> voter,
> >> >>> > > XML
> >> >>> > > configuration
> >> >>> > > capabilities.
> >> >>> >
> >> >>> > Not sure what to say here yet. But I think non-Spring users
should
> >> be
> >> >>> taken
> >> >>> > care of too. Or when simpler cases are dealt with then perhaps
> >> there's
> >> >>> no
> >> >>> > need to bring in Spring security. Perhaps the utility
> authorization
> >> >>> > interceptors should just not be used when Spring Security is
> >> preferred
> >> >>> ?
> >> >>> >
> >> >>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
> >> >>> CXF-BC
> >> >>> > > currently has a limited capability to select the credentials to
> >> >>> > > authenticate
> >> >>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
> >> >>> delegates
> >> >>> > > authentication to the JBI container through a ServiceMix
> >> components
> >> >>> > > authentication service abstraction of JAAS. Whatever solution
> we
> >> >>> have
> >> >>> > > for 1
> >> >>> > > and 2 would help out the component if the ServiceMix
> >> authentication
> >> >>> > > service abstraction could be wired up in lieu of whatever we
> >> provide
> >> >>> out
> >> >>> > > of the box.
> >> >>> >
> >> >>> > I'm not planning to contribute to ServiceMix. I agree though that
> an
> >> >>> ideal
> >> >>> > solution will meet multiple requirements
> >> >>> >
> >> >>> > thanks, Sergey
> >> >>> >
> >> >>> > > -----Original Message-----
> >> >>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >> >>> > > Sent: Wednesday, April 07, 2010 10:11 AM
> >> >>> > > To: dev@cxf.apache.org
> >> >>> > > Subject: Using WS-Security UsernameToken to authenticate users
> and
> >> >>> > > populate SecurityContexts
> >> >>> > >
> >> >>> > > Hi
> >> >>> > >
> >> >>> > > I've been looking recently at extending the CXF WS-Security
> >> component
> >> >>> > > such that a current UsernameToken could be used by custom
> >> >>> interceptors
> >> >>> > > to authenticate a user with the external security systems and,
> if
> >> >>> > > possible, provide enough information for CXF to populate a
> >> >>> > > SecurityContext [1] to be used later on for
> >> >>> > > authorization decisions.
> >> >>> > >
> >> >>> > > Here is the approach I've taken so far.
> >> >>> > > A custom interceptor extends
> >> >>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the
> only
> >> >>> method
> >> >>> > > it overrides is
> >> >>> > >
> >> >>> > > abstract Subject createSubject(String name, String password,
> >> boolean
> >> >>> > > isDigest,
> >> >>> > >
> >> >>> > > String nonce,
> >> >>> > > String created) throws
> >> >>> > >
> >> >>> > > WSSecurityException;
> >> >>> > >
> >> >>> > >
> >> >>> > > For example, see [3].
> >> >>> > >
> >> >>> > > The idea here is that a custom interceptor interfaces whichever
> >> way
> >> >>> it
> >> >>> > > needs
> >> >>> > > to with the external system and populates a Subject following
> this
> >> >>> simple
> >> >>> > > rule : first Subject principal is the current user (identified
> by
> >> a
> >> >>> > > 'name' argument), followed by one or more Groups this user is a
> >> >>> member
> >> >>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use
> this
> >> >>> > > Subject to provide a functional SecurityContext instance.
> >> >>> > >
> >> >>> > > This is the first part, next is how to utilize a
SecurityContext
> >> and
> >> >>> get
> >> >>> > > the
> >> >>> > > expected roles associated one way or the other with a current
> >> method
> >> >>> to
> >> >>> > > be invoked. There's a number of usual options available here,
> >> perhaps
> >> >>> > > even SpringSecurity can be used now that SecurityContext is
> >> >>> available,
> >> >>> > > or application code or other custom CXF interceptor can check
> the
> >> >>> known
> >> >>> > > roles against SecurityContext.
> >> >>> > >
> >> >>> > > I've also added AbstractAuthorizingInInterceptor interceptor
> which
> >> >>> custom
> >> >>> > > interceptors can override and return a list of expected roles
> >> given
> >> a
> >> >>> > > (service) Method to be invoked upon,
> >> AbstractAuthorizingInInterceptor
> >> >>> > > will then ask available SecurityContext to match the roles; one
> >> >>> concrete
> >> >>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
> >> injected
> >> >>> > > with a
> >> >>> > > method specific or class (applying to all methods) roles.
> Another
> >> >>> > > implementation which I will likely add later on will be
injected
> >> with
> >> >>> a
> >> >>> > > name
> >> >>> > > of annotation such as RolesAlloved and it will introspect a
> method
> >> >>> and
> >> >>> > > its class.
> >> >>> > >
> >> >>> > > Note that I haven't looked into the case when a policy runtimes
> >> adds
> >> >>> the
> >> >>> > > interceptors yet (as opposed to interceptors being configured
> form
> >> >>> > > Spring/programmatically). I think an optional contextual
> property
> >> >>> will
> >> >>> > > need to be setup in such cases for users be able to indicate
> that
> >> say
> >> >>> an
> >> >>> > > interceptor such as [3] has to be used as opposed to
> >> >>> WSS4JInInterceptor,
> >> >>> > > etc.
> >> >>> > >
> >> >>> > > I'm going to validate this approach with JBoss CXF. If you have
> >> any
> >> >>> > > comments
> >> >>> > > then please let me know.
> >> >>> > >
> >> >>> > > I think we may have a simpler alternative eventually to the way
> >> >>> > > authorization decisions are made. [1]-[3] is specific to
> >> ws-security,
> >> >>> but
> >> >>> > > [4]-[5] is not
> >> >>> > >
> >> >>> > > cheers, Sergey
> >> >>> > >
> >> >>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
> >> >>> > > [2]
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
> >> >>> > > g/a
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
> >> >>> > > tor<
> >> >>>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
> >> >>> > >
> >> >>>
> >>
> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
> >> >>> > > ngInterceptor> .java
> >> >>> > > [3]
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
> >> >>> > > g/a
> >> >>> > >
> >> >>>
> >>
pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
> >> >>> > > /
> >> >>>
> >>
> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
> >> >>> > >
> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
> >> >>> [4]
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> >> >>> > > e/c
> >> >>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
> >> >>> http://svn
> >> >>> > > .
> >> >>>
> >>
> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
> >> >>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> >> >>> > > e/c
> >> >>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
> >> >>> http://svn.apa
> >> >>> > >
> >> >>>
> >>
> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
> >> >>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
> >> >>>
> >> >>> --
> >> >>> Daniel Kulp
> >> >>> dkulp@apache.org
> >> >>> http://dankulp.com/blog
> >> >>>
> >> >>
> >> >>
> >> >
> >>
> >
> >
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
On Fri, Apr 23, 2010 at 2:53 PM, David Valeri <dv...@apache.org> wrote:
> I have attached the diagrams to the ticket in JIRA.
>
thanks...
>
> The eventual interceptor that handles a profile would be specific to the
> security implementation used as it ultimately needs to look at results that
> are in a proprietary form (WSS4J, METRO, etc.). What the framework
> provides
> is some scaffolding to handle the boilerplate stuff such that concrete
> interceptors only have to deal with extracting credentials and it allows
> end
> users to substitute their own interceptor implementations for whatever
> profiles they need to support.
>
Now, here is a slightly alternative approach to the requiring an
introduction of delegate interceptors.
You've mentioned the fact that WSS4JInInterceptor would still need to be
configured to skip the UT's password validation.
Your diagram also shows WSS4SecurityProfileEvaluator, which is a delegate
interceptor.
Honestly, I'm not sure if/when CXF will switch from using WSS4J given that
existing users already depend on it; may be it is a bit early to start
thinking of CXF switching from WSS4J just because it enforces the UT
authentication which can be easily disabled right now.
Thus, perhaps things will get simplified if WSS4JInInterceptor just gets
optionally injected with say AuthenticationStrategy which will get passed
WSS4J results (note, the domain will be set as the AuthenticationStrategy
property) and will return SecurityContext provided the authentication has
been successful. This can make the security profile block redundant. So when
subclassing becomes too limiting, users would just register a single
AuthenticationStrategy which can take care of all the understood tokens, as
opposed to users having to choose between BT, UT, etc interceptors as
proposed in a diagramm.
And then, if we have a policy-first case, users will just register
AuthenticationStrategy as a jaxws property for a given endpoint.
I still may not grasping your idea but just trying to see where/how things
could get simplified.I think I'd try later on just to write a test which
would use say a BinaryToken to authenticate a user. And then I may have a
better/stronger opinion about how things can get improved/simplified.
cheers, Sergey
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Friday, April 23, 2010 9:16 AM
> To: dev@cxf.apache.org
> Subject: Re: Using WS-Security UsernameToken to authenticate users and
> populate SecurityContexts
>
> Hi David
>
> I've been thinking a bit more about your idea. As I said it looks
> interesting but what have not quite understood is how you're planning to
> hide the WSS4J specifics from the interceptors further in the chain.
> Example, the Principal that WSS4J UT processor returns has an info about
> the
> type of password (digest or not) which is made available to
> (Abstract)WSS4J(SecurityContext)Interceptor or UsernameTokenInterceptor
> subclasses without them having to be aware of WSS4J. Both interceptors can
> make the actual Principal available to other interceptors but it is just a
> Principal interface...
>
> So I'm presuming, without seeing your diagrams, WSS4JInInterceptor would
> need to process the WWS4J response and store all the "Credential" objects
> in
> a current Message, alongside with properties specifying the types of these
> Credentials. Authenticating interceptors would then check a type, cast a
> given Credential to say "UTCredential" (with all the details like password
> type, etc) or BinaryTokenCredential, etc... and do whatever they need to.
> This could indeed present an option to the subclassing one. As I said, IMHO
> the latter one is good enough on its own when we have a UT only to deal
> with
> but I'm positive about seeing a more comprehensive approach being explored
> and realized
>
> As I said, having some system test (as a patch for ex) would help to see
> the
> whole picture you're having in mind.
>
> cheers, Sergey
>
> On Thu, Apr 22, 2010 at 10:18 PM, Sergey Beryozkin
> <sb...@gmail.com>wrote:
>
> > Hi
> >
> > On Thu, Apr 22, 2010 at 9:14 PM, David Valeri <dv...@apache.org>
> wrote:
> >
> >> Attached are some quick and dirty class/seq diagrams that outline a
> >> slightly
> >> different approach to determining which credentials to authenticate,
> >> choosing how to extract them, and then actually performing the
> >> authentication.
> >>
> >>
> > I do not see the attachments, perhaps you may want to attach them to the
> > actual JIRA
> > (https://issues.apache.org/jira/browse/CXF-2754)
> >
> >
> >> This approach would still require configuring your customized UT
> Processor
> >> in WSS4J in order to disable WSS4Js clumsy authentication system but
> moves
> >> the work of creating the SecurityContext and JAAS subject out of the
> WSS4J
> >> interceptors and into generic authentication framework. It looks like
> >> WSS4JInInterceptor simply looks for the first principal it finds in the
> >> WSS4J results and sends that on its way. When multiple tokens appear in
> a
> >> message, this approach may not always grab the one the application
> really
> >> requires.
> >>
> >>
> > OK. I think that for a java-first case utilizing
> > AbstractSecurityContextProvidingInterceptor
> > would ensure a Principal associated with a Subject is the one obtained
> from
> > a UTProcessor.
> > Ditto for a policy-first case where a UsernameTakenInterceptor subclass
> is
> > used.
> >
> >
> >> This approach works after the WSS4J security processing completes and
> >> examines the results from WSS4J, or another security framework if we
> ever
> >> use one, and determines which profile is in effect. A delegate
> >> interceptor
> >> is then called to extract the correct user credentials from the message
> >> and
> >> perform any additional validation that is needed for a given profile.
> The
> >> extracted credentials are then passed to an AuthenticationStrategy to
> >> perform the actual authentication. The AuthenticationService would
> return
> >> something like a JAAS Subject that is then used to create the CXF
> >> SecurityContext. As you can see, the "Credentials" concept is pretty
> >> vague
> >> as there are many different types of credentials out there. I feel that
> >> the
> >> most common two are X509 certificates and Username Tokens.
> >>
> >
> > Sounds like you're proposing a serious and generic solution which is
> great.
> > But I'd be great if you could do a bit of prototyping so that we can see
> > how things (like configuration, etc) actually look like ?
> > I believe one of your main concerns is that a given request may contain
> > multiple "Credentials" and thus the approach proposed here
> > would not necessarily work. Thus seeing a more concrete example could
> help,
> > me at least :-)
> >
> >
> >
> >>
> >> This approach requires many more classes and could be more complex to
> >> configure.
> >
> >
> > Well, if it will help addressing some advanced scenarios or make it
> simpler
> > to deal with UT/BT/etc in a single uniform way then it would be
> > justifiable...The thing I like about the approach I've employed for
> dealing
> > with UTokens is that it is IMHO very simple and straightforward,
> especially
> > in the policy-first case. It is up to the interceptor which creates a
> > Subject to interact with a 3rd party AuthenticationService (ex, something
> > that has been initially tested with JBoss SecuritySystem), essentially,
> in
> > your terms, it is this custom interceptor which acts as an
> > 'AuthenticationStrategy', every other custom interceptor just implements
> its
> > own strategy.
> >
> > Note, I'm not saying this solution is adequate for all the cases but I
> > think it works for cases where UTs are involved, possibly encrypted, with
> > plain or digested passwords. But personally I'd also welcome a more
> thorough
> > solution/framework and looks like you have all the experience for driving
> it
> > forward :-). I'm not ready to commit to working on this framework but
> > depending on how things go and what requirements will be there I may be
> able
> > to start contributing and helping with implementing it
> >
> >
> >> I have not thoroughly been over what the default SecurityProfile
> >> evaluator should be like nor do I know what concrete implementations of
> >> AbstractSecurityContextProvidingInterceptor should be provided. What I
> >> feel
> >> to be the three most common interceptor instances are listed in the
> class
> >> diagram. As for the default SecurityProfileChooser, I initially suggest
> >> that it simply allows the user to enable/disable no security, TLS, BST,
> >> and
> >> UT while allowing the end user to configure the desired precedence of
> each
> >> profile over the other.
> >>
> >> This approach can easily work with Spring Security as an
> >> AuthenticationService implementation.
> >>
> >>
> > sounds great indeed.
> >
> > thanks, Sergey
> >
> >
> >> -----Original Message-----
> >> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >> Sent: Wednesday, April 21, 2010 5:47 PM
> >> To: Daniel Kulp
> >> Cc: dev@cxf.apache.org
> >> Subject: Re: Using WS-Security UsernameToken to authenticate users and
> >> populate SecurityContexts
> >>
> >> I added a system test for a policy first case and refactored few bits
> >> along
> >> the way, as well as closed [1] as 'Wont fix', at least for now.
> >>
> >> I've just updated UsernameTokenInterceptor[1] so that a (WSS4J)
> principal
> >> can be created directly if a message property disabling the validation
> of
> >> passwords has been set.
> >>
> >> This property can be set as a jaxws contextual property in which case
> >> interceptors further in the chain will be able to get the
> >> (unauthenticated)
> >> Principal, validate it, and set a SecurityContext as needed.
> >>
> >> Another approach used in the system test is to write a custom
> >> interceptor[3]
> >> extending UsernameTokenInterceptor and disable the validation from
> there.
> >> This custom interceptor is currently being registered by setting a bus
> >> property, see [4]. Note that a jaxws endpoint adds
> >> SimpleAuthorizationInterceptor only and has no callbacks registered.
> >>
> >> See [5] for more details.
> >>
> >> It looks quite reasonable to me at the moment, perhaps there could be a
> >> simpler way to register custom interceptors.
> >>
> >> Dan, you've mentioned the fact you were planning to refactor some of the
> >> policy interceptors so that WSS4JInterceptor is not used for
> UsernameToken
> >> processing at all. I'd appreciate if you could look into this
> refactoring
> >> yourself, there could be some subtleties there I'm not aware of. Also,
> >> personally I'd prefer registering a noop processor with WSS4J rather
> >> adding
> >> a flag to WSS4J, perhaps this noop processor can be used for handling
> >> other
> >> types of tokens, using an approach similar to the one taken by
> >> UsernameTokenInterceptor, unless yourself, David V, others have
> something
> >> else in mind...
> >>
> >> cheers, Sergey
> >>
> >> [1] https://issues.apache.org/jira/browse/WSS-229
> >> [2]
> >>
> >>
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
> >> pache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
> >> [3]
> >>
> >>
>
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
> >>
>
> g/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java<h
> ttp://
> svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%
>
> 0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java<http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%%0A0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java>
> >
> >> [4]
> >>
> >>
>
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
> >>
>
> g/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml<http
> ://
> svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%0Ag
> /apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml>
> >> [5] http://svn.apache.org/viewvc?rev=936521&view=rev
> >>
> >>
> >> On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin
> >> <sb...@gmail.com>wrote:
> >>
> >> > Hi
> >> >
> >> > I've added an initial patch for addressing a policy-first case, see
> [1].
> >> > It's a patch because it depends on another one I submitted to WSS4J
> [2].
> >> > Both patches need more work (tests, etc) but I'd just like to initiate
> a
> >> > discussion/review.
> >> >
> >> > The idea behind [1] is quite similar to the one used in supporting a
> >> > java-first case, where a custom interceptor extends an
> >> > AbstractWSS4JSecurityContextPr
> >> > oviding interceptor. But is is much simpler in [1] where
> >> > UsernameTokenProcessor may be optionally extended and its
> createSubject
> >> > method be overridden. Provided [2] gets applied then a subclass will
> >> just
> >> > have a property set disabling the (WSS4J) validation of passwords and
> >> will
> >> > do its own validation in createSubject method.
> >> >
> >> > This is really all what will be needed in simple cases, where a
> >> > DefaultSecurityContext will do, but optionally, createSecurityContext
> >> can
> >> > be overridden too.
> >> >
> >> > A user would need to set a bus property
> >> > "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a
> >> custom
> >> > interceptor which will indicate to the WSSecurityPolicyLoader that a
> >> custom
> >> > UsernameTokenProcessor subclass will need to be loaded.
> >> >
> >> > Similar approach can be employed for handling other types of tokens.
> >> >
> >> > cheers, Sergey
> >> >
> >> > [1] https://issues.apache.org/jira/browse/CXF-2754
> >> > [2] https://issues.apache.org/jira/browse/WSS-229
> >> >
> >> >
> >> > On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin
> >> <sb...@gmail.com>wrote:
> >> >
> >> >> Just realized I did not CC tp dev when replying to Dan the other day
> :
> >> >>
> >> >> Hi Dan
> >> >>
> >> >>
> >> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org>
> wrote:
> >> >>
> >> >>>
> >> >>> My main "concern" with the implementation of this is that it's done
> as
> >> a
> >> >>> direct subclass of the WSS4JInInterceptor and thus not really usable
> >> by
> >> >>> the
> >> >>> policy based endpoints as those interceptors subclass
> >> WSS4JInInterceptor
> >> >>> as
> >> >>> well.
> >> >>>
> >> >>> I think the better approach may be to add a flag to wss4j (I can
> help
> >> >>> commit
> >> >>> changes there if needed) to have it not do any UserName token
> >> processing
> >> >>> at
> >> >>> all. (aside: this may be doable without changes to wss4j by
> >> >>> registering our
> >> >>> own "do nothing processor") Then, have another interceptor that
> >> runs
> >> >>> after
> >> >>> the WSS4JInInterceptor that would actually handle the UsernameToken
> >> and
> >> >>> verify
> >> >>> anything it needs and such.
> >> >>>
> >> >>
> >> >> This sounds like a very good idea, I agree the proposed approach
> won't
> >> do
> >> >> for the cases where policies drive the
> >> >> creation of interceptors.
> >> >>
> >> >> Having said that, I think the abstract utility interceptor extending
> >> >> WSS4JInInterceptor
> >> >> may still be used in cases where users start from manually
> configuring
> >> >> jaxws endpoints. In these cases they'd need to
> >> >> list up to 3 interceptors (the one which extends
> >> >> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor
> if
> >> the
> >> >> authorization is needed plus may be a SAAJ one) but otherwise, when
> say
> >> a
> >> >> clear text password has been encrypted, they'd still need to specify
> >> >> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
> >> >> UsernameTokenInterceptor, etc.
> >> >>
> >> >> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit
> >> complicated
> >> >> due to the fact it blocks the WSS4J digest checks and thus also
> creates
> >> a
> >> >> security engine per every request, but it all will be gone in due
> >> time...
> >> >>
> >> >>
> >> >>>
> >> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
> >> >>> There is
> >> >>> currently some duplicated code between the
> >> PolicyBasedWSS4JIinInterceptor
> >> >>> and
> >> >>> the new UsernameTokenInterceptor that could be eliminated by having
> >> the
> >> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
> >> delegate
> >> >>> that
> >> >>> completely to the UsernameTokenInterceptor.
> >> >>>
> >> >>
> >> >> What I will do is I will experiment with the test you added (thanks
> >> :-))
> >> >> and see how UsernameTokenInterceptor can be refactored
> >> >> so that a subclass can get an easy access to password, nonce, etc. I
> >> think
> >> >> I will need to come up with a contextual property so that a custom
> >> >> UsernameTokenInterceptor can be installed if needed. Or may be
> >> >> UsernameTokenInterceptor can store the details in a message to be
> later
> >> >> retrieved and processed for creating SecurityContext - but I'm not
> sure
> >> >> about it just yet.
> >> >>
> >> >>
> >> >>>
> >> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
> >> >>> encryption/signature stuff and then let the authorization
> validations
> >> >>> stuff to
> >> >>> later interceptors. That would include things like key validation
> >> >>> checking
> >> >>> and stuff as well. Probably SAML token validation as well.
> >> >>>
> >> >>>
> >> >> sounds good
> >> >>
> >> >> cheers, Sergey
> >> >>
> >> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org>
> wrote:
> >> >>
> >> >>>
> >> >>> My main "concern" with the implementation of this is that it's done
> as
> >> a
> >> >>> direct subclass of the WSS4JInInterceptor and thus not really usable
> >> by
> >> >>> the
> >> >>> policy based endpoints as those interceptors subclass
> >> WSS4JInInterceptor
> >> >>> as
> >> >>> well.
> >> >>>
> >> >>> I think the better approach may be to add a flag to wss4j (I can
> help
> >> >>> commit
> >> >>> changes there if needed) to have it not do any UserName token
> >> processing
> >> >>> at
> >> >>> all. (aside: this may be doable without changes to wss4j by
> >> >>> registering our
> >> >>> own "do nothing processor") Then, have another interceptor that
> >> runs
> >> >>> after
> >> >>> the WSS4JInInterceptor that would actually handle the UsernameToken
> >> and
> >> >>> verify
> >> >>> anything it needs and such.
> >> >>>
> >> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
> >> >>> There is
> >> >>> currently some duplicated code between the
> >> PolicyBasedWSS4JIinInterceptor
> >> >>> and
> >> >>> the new UsernameTokenInterceptor that could be eliminated by having
> >> the
> >> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
> >> delegate
> >> >>> that
> >> >>> completely to the UsernameTokenInterceptor.
> >> >>>
> >> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
> >> >>> encryption/signature stuff and then let the authorization
> validations
> >> >>> stuff to
> >> >>> later interceptors. That would include things like key validation
> >> >>> checking
> >> >>> and stuff as well. Probably SAML token validation as well.
> >> >>>
> >> >>> Dan
> >> >>>
> >> >>>
> >> >>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
> >> >>> > Hi David
> >> >>> >
> >> >>> > thanks for the comments...
> >> >>> >
> >> >>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
> >> >>> wrote:
> >> >>> > > Sergey,
> >> >>> > >
> >> >>> > > I think this type of functionality would be very useful to a
> >> number
> >> >>> of
> >> >>> > > folks. I have built two similar capabilities for clients very
> >> >>> recently
> >> >>> > > using CXF and Spring Security. Based on the code provided
> below,
> >> I
> >> >>> have
> >> >>> > > several points that I would like to see addressed in a solution.
> >> >>> > >
> >> >>> > > 1) Architecture to support more than just UsernameTokens. I
> have
> >> >>> worked
> >> >>> > > with systems that need to authenticate a user using
> >> UsernameTokens,
> >> >>> > > BinarySecurityTokens, SAML Assertions, and a combination of more
> >> than
> >> >>> one
> >> >>> > > of
> >> >>> > > these at a time.
> >> >>> >
> >> >>> > Supporting UsernameTokens is the initial requirement. At the
> moment
> >> I
> >> >>> do
> >> >>> > not even know how BinarySecurityTokens or SAML Assertions are
> >> >>> > processed/validated in CXF or WSS4J.
> >> >>> >
> >> >>> > > For the most part, WSS4J simply validates the structural
> >> >>> > > details of security. That is, signature validity, trust
> chaining
> >> of
> >> >>> > > digital
> >> >>> > > certificates, etc. As Glen pointed out with his reference to
> >> >>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
> >> >>> performs
> >> >>> > > its
> >> >>> > > own password checking (authentication). Unfortunately, WSS4J
> >> doesn't
> >> >>> > > provide hooks for authenticating other forms of credentials that
> I
> >> >>> have
> >> >>> > > listed above (I don't consider trust to be equivalent to
> >> >>> authentication).
> >> >>> > > It would be best if the authentication interface supported
> >> multiple
> >> >>> > > credential types and allowed for authentication to be performed
> in
> >> a
> >> >>> > > single location in the same manner every time (not sometimes in
> >> the
> >> >>> > > WSS4J callback and sometimes in another interceptor for non-UT
> >> based
> >> >>> > > credentials).
> >> >>> >
> >> >>> > Makes sense. Assuming it is WSS4J which validates (the structure
> of)
> >> >>> > BinarySecurityTokens then
> >> >>> AbstractWSS4JSecurityContextProvidingInterceptor
> >> >>> > can also implement a processor for BinarySecurityTokens and
> delegate
> >> to
> >> >>> > subclass to authenticate and setup a subject. Some extra methods
> >> will
> >> >>> need
> >> >>> > to be added, to be optionally overridden.
> >> >>> >
> >> >>> > If it is not only WSS4J which is involved then perhaps another
> >> option
> >> >>> is to
> >> >>> > store (from WSS4J callback handler, etc) relevant details such
> >> username
> >> >>> > token details, etc to be acted upon by other interceptors.
> >> >>> >
> >> >>> > > That
> >> >>> > > last bit there means disabling WSS4J's password authentication
> >> since
> >> >>> it
> >> >>> > > gets
> >> >>> > > in the way of doing it later in our own interceptor.
> >> >>> >
> >> >>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
> >> >>> > implementing a simplified UsernameTokenProcessor
> >> >>> >
> >> >>> > > 2) Allow for end-user flexibility in choosing the credentials
> they
> >> >>> want
> >> >>> > > to authenticate. For instance, each user is going to have their
> >> own
> >> >>> > > security profiles and authentication requirements. For
> instance,
> >> a
> >> >>> > > message contains a UT for a portal user and a digital signature
> >> from
> >> >>> the
> >> >>> > > portal (I know using
> >> >>> > > a SAML Assertion would be better here, but people still do it
> this
> >> >>> way).
> >> >>> > > Each organization will have different requirements as to which
> >> >>> > > credentials get authenticated and what needs to end up in the
> >> >>> security
> >> >>> > > context.
> >> >>> >
> >> >>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor
> >> subclasses
> >> >>> > should be able to do it, for username tokens and other tokens
> later
> >> on.
> >> >>> >
> >> >>> > > 3) Decouple the authentication interface from WSS4J. What is
> >> passed
> >> >>> in
> >> >>> > > needs to be abstracted enough that it can work with other
> >> WS-Security
> >> >>> > > libraries as well.
> >> >>> >
> >> >>> > the only WSS4J class which is leaked at the moment is
> >> >>> WSSecurityException.
> >> >>> > Perhaps we can come up later on with a different more generic
> >> approach
> >> >>> > which does not depend on WSS4J at all. As Dan indicated, in some
> >> cases
> >> >>> > WSS4JInInterceptor is not even used, so that case will need to be
> >> >>> > addressed. Experimenting wuth binary tokens might help with
> >> identifying
> >> >>> > another solution.
> >> >>> >
> >> >>> > > 4) It would be nice to be able to perform authorization using
> >> >>> something
> >> >>> > > like
> >> >>> > > Spring Security at the service operation level. With a POJO or
> >> >>> JAX-WS
> >> >>> > > based
> >> >>> > > service, one can just use Spring Security's method interceptor
> to
> >> >>> provide
> >> >>> > > such security; however, in situations where one only has a WSDL
> >> based
> >> >>> > > service or a provider style service, a method interceptor can't
> be
> >> >>> used.
> >> >>> > >
> >> >>> > > It
> >> >>> > >
> >> >>> > > would be nice to provide a hook into Spring Security to allow
> >> >>> end-users
> >> >>> > > to specify role based authorization policy based on a
> combination
> >> of
> >> >>> > > interface,
> >> >>> > > instance, and operation names. It seems like your
> >> >>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor
> >> are
> >> >>> > > looking in this direction, but I think it would be best if we
> can
> >> >>> stand
> >> >>> > > on the shoulders of the Spring Security giant as much as
> possible
> >> so
> >> >>> > > that we can take advantage of their rich authorization manager,
> >> >>> voter,
> >> >>> > > XML
> >> >>> > > configuration
> >> >>> > > capabilities.
> >> >>> >
> >> >>> > Not sure what to say here yet. But I think non-Spring users should
> >> be
> >> >>> taken
> >> >>> > care of too. Or when simpler cases are dealt with then perhaps
> >> there's
> >> >>> no
> >> >>> > need to bring in Spring security. Perhaps the utility
> authorization
> >> >>> > interceptors should just not be used when Spring Security is
> >> preferred
> >> >>> ?
> >> >>> >
> >> >>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
> >> >>> CXF-BC
> >> >>> > > currently has a limited capability to select the credentials to
> >> >>> > > authenticate
> >> >>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
> >> >>> delegates
> >> >>> > > authentication to the JBI container through a ServiceMix
> >> components
> >> >>> > > authentication service abstraction of JAAS. Whatever solution
> we
> >> >>> have
> >> >>> > > for 1
> >> >>> > > and 2 would help out the component if the ServiceMix
> >> authentication
> >> >>> > > service abstraction could be wired up in lieu of whatever we
> >> provide
> >> >>> out
> >> >>> > > of the box.
> >> >>> >
> >> >>> > I'm not planning to contribute to ServiceMix. I agree though that
> an
> >> >>> ideal
> >> >>> > solution will meet multiple requirements
> >> >>> >
> >> >>> > thanks, Sergey
> >> >>> >
> >> >>> > > -----Original Message-----
> >> >>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >> >>> > > Sent: Wednesday, April 07, 2010 10:11 AM
> >> >>> > > To: dev@cxf.apache.org
> >> >>> > > Subject: Using WS-Security UsernameToken to authenticate users
> and
> >> >>> > > populate SecurityContexts
> >> >>> > >
> >> >>> > > Hi
> >> >>> > >
> >> >>> > > I've been looking recently at extending the CXF WS-Security
> >> component
> >> >>> > > such that a current UsernameToken could be used by custom
> >> >>> interceptors
> >> >>> > > to authenticate a user with the external security systems and,
> if
> >> >>> > > possible, provide enough information for CXF to populate a
> >> >>> > > SecurityContext [1] to be used later on for
> >> >>> > > authorization decisions.
> >> >>> > >
> >> >>> > > Here is the approach I've taken so far.
> >> >>> > > A custom interceptor extends
> >> >>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the
> only
> >> >>> method
> >> >>> > > it overrides is
> >> >>> > >
> >> >>> > > abstract Subject createSubject(String name, String password,
> >> boolean
> >> >>> > > isDigest,
> >> >>> > >
> >> >>> > > String nonce,
> >> >>> > > String created) throws
> >> >>> > >
> >> >>> > > WSSecurityException;
> >> >>> > >
> >> >>> > >
> >> >>> > > For example, see [3].
> >> >>> > >
> >> >>> > > The idea here is that a custom interceptor interfaces whichever
> >> way
> >> >>> it
> >> >>> > > needs
> >> >>> > > to with the external system and populates a Subject following
> this
> >> >>> simple
> >> >>> > > rule : first Subject principal is the current user (identified
> by
> >> a
> >> >>> > > 'name' argument), followed by one or more Groups this user is a
> >> >>> member
> >> >>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use
> this
> >> >>> > > Subject to provide a functional SecurityContext instance.
> >> >>> > >
> >> >>> > > This is the first part, next is how to utilize a SecurityContext
> >> and
> >> >>> get
> >> >>> > > the
> >> >>> > > expected roles associated one way or the other with a current
> >> method
> >> >>> to
> >> >>> > > be invoked. There's a number of usual options available here,
> >> perhaps
> >> >>> > > even SpringSecurity can be used now that SecurityContext is
> >> >>> available,
> >> >>> > > or application code or other custom CXF interceptor can check
> the
> >> >>> known
> >> >>> > > roles against SecurityContext.
> >> >>> > >
> >> >>> > > I've also added AbstractAuthorizingInInterceptor interceptor
> which
> >> >>> custom
> >> >>> > > interceptors can override and return a list of expected roles
> >> given
> >> a
> >> >>> > > (service) Method to be invoked upon,
> >> AbstractAuthorizingInInterceptor
> >> >>> > > will then ask available SecurityContext to match the roles; one
> >> >>> concrete
> >> >>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
> >> injected
> >> >>> > > with a
> >> >>> > > method specific or class (applying to all methods) roles.
> Another
> >> >>> > > implementation which I will likely add later on will be injected
> >> with
> >> >>> a
> >> >>> > > name
> >> >>> > > of annotation such as RolesAlloved and it will introspect a
> method
> >> >>> and
> >> >>> > > its class.
> >> >>> > >
> >> >>> > > Note that I haven't looked into the case when a policy runtimes
> >> adds
> >> >>> the
> >> >>> > > interceptors yet (as opposed to interceptors being configured
> form
> >> >>> > > Spring/programmatically). I think an optional contextual
> property
> >> >>> will
> >> >>> > > need to be setup in such cases for users be able to indicate
> that
> >> say
> >> >>> an
> >> >>> > > interceptor such as [3] has to be used as opposed to
> >> >>> WSS4JInInterceptor,
> >> >>> > > etc.
> >> >>> > >
> >> >>> > > I'm going to validate this approach with JBoss CXF. If you have
> >> any
> >> >>> > > comments
> >> >>> > > then please let me know.
> >> >>> > >
> >> >>> > > I think we may have a simpler alternative eventually to the way
> >> >>> > > authorization decisions are made. [1]-[3] is specific to
> >> ws-security,
> >> >>> but
> >> >>> > > [4]-[5] is not
> >> >>> > >
> >> >>> > > cheers, Sergey
> >> >>> > >
> >> >>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
> >> >>> > > [2]
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
> >> >>> > > g/a
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
> >> >>> > > tor<
> >> >>>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
> >> >>> > >
> >> >>>
> >>
> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
> >> >>> > > ngInterceptor> .java
> >> >>> > > [3]
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
> >> >>> > > g/a
> >> >>> > >
> >> >>>
> >> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
> >> >>> > > /
> >> >>>
> >>
> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
> >> >>> > >
> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
> >> >>> [4]
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> >> >>> > > e/c
> >> >>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
> >> >>> http://svn
> >> >>> > > .
> >> >>>
> >>
> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
> >> >>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
> >> >>> > >
> >> >>> > >
> >> >>>
> >>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> >> >>> > > e/c
> >> >>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
> >> >>> http://svn.apa
> >> >>> > >
> >> >>>
> >>
> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
> >> >>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
> >> >>>
> >> >>> --
> >> >>> Daniel Kulp
> >> >>> dkulp@apache.org
> >> >>> http://dankulp.com/blog
> >> >>>
> >> >>
> >> >>
> >> >
> >>
> >
> >
>
>
RE: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Posted by David Valeri <dv...@apache.org>.
I have attached the diagrams to the ticket in JIRA.
The eventual interceptor that handles a profile would be specific to the
security implementation used as it ultimately needs to look at results that
are in a proprietary form (WSS4J, METRO, etc.). What the framework provides
is some scaffolding to handle the boilerplate stuff such that concrete
interceptors only have to deal with extracting credentials and it allows end
users to substitute their own interceptor implementations for whatever
profiles they need to support.
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Friday, April 23, 2010 9:16 AM
To: dev@cxf.apache.org
Subject: Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Hi David
I've been thinking a bit more about your idea. As I said it looks
interesting but what have not quite understood is how you're planning to
hide the WSS4J specifics from the interceptors further in the chain.
Example, the Principal that WSS4J UT processor returns has an info about the
type of password (digest or not) which is made available to
(Abstract)WSS4J(SecurityContext)Interceptor or UsernameTokenInterceptor
subclasses without them having to be aware of WSS4J. Both interceptors can
make the actual Principal available to other interceptors but it is just a
Principal interface...
So I'm presuming, without seeing your diagrams, WSS4JInInterceptor would
need to process the WWS4J response and store all the "Credential" objects in
a current Message, alongside with properties specifying the types of these
Credentials. Authenticating interceptors would then check a type, cast a
given Credential to say "UTCredential" (with all the details like password
type, etc) or BinaryTokenCredential, etc... and do whatever they need to.
This could indeed present an option to the subclassing one. As I said, IMHO
the latter one is good enough on its own when we have a UT only to deal with
but I'm positive about seeing a more comprehensive approach being explored
and realized
As I said, having some system test (as a patch for ex) would help to see the
whole picture you're having in mind.
cheers, Sergey
On Thu, Apr 22, 2010 at 10:18 PM, Sergey Beryozkin
<sb...@gmail.com>wrote:
> Hi
>
> On Thu, Apr 22, 2010 at 9:14 PM, David Valeri <dv...@apache.org> wrote:
>
>> Attached are some quick and dirty class/seq diagrams that outline a
>> slightly
>> different approach to determining which credentials to authenticate,
>> choosing how to extract them, and then actually performing the
>> authentication.
>>
>>
> I do not see the attachments, perhaps you may want to attach them to the
> actual JIRA
> (https://issues.apache.org/jira/browse/CXF-2754)
>
>
>> This approach would still require configuring your customized UT
Processor
>> in WSS4J in order to disable WSS4Js clumsy authentication system but
moves
>> the work of creating the SecurityContext and JAAS subject out of the
WSS4J
>> interceptors and into generic authentication framework. It looks like
>> WSS4JInInterceptor simply looks for the first principal it finds in the
>> WSS4J results and sends that on its way. When multiple tokens appear in
a
>> message, this approach may not always grab the one the application really
>> requires.
>>
>>
> OK. I think that for a java-first case utilizing
> AbstractSecurityContextProvidingInterceptor
> would ensure a Principal associated with a Subject is the one obtained
from
> a UTProcessor.
> Ditto for a policy-first case where a UsernameTakenInterceptor subclass is
> used.
>
>
>> This approach works after the WSS4J security processing completes and
>> examines the results from WSS4J, or another security framework if we ever
>> use one, and determines which profile is in effect. A delegate
>> interceptor
>> is then called to extract the correct user credentials from the message
>> and
>> perform any additional validation that is needed for a given profile.
The
>> extracted credentials are then passed to an AuthenticationStrategy to
>> perform the actual authentication. The AuthenticationService would
return
>> something like a JAAS Subject that is then used to create the CXF
>> SecurityContext. As you can see, the "Credentials" concept is pretty
>> vague
>> as there are many different types of credentials out there. I feel that
>> the
>> most common two are X509 certificates and Username Tokens.
>>
>
> Sounds like you're proposing a serious and generic solution which is
great.
> But I'd be great if you could do a bit of prototyping so that we can see
> how things (like configuration, etc) actually look like ?
> I believe one of your main concerns is that a given request may contain
> multiple "Credentials" and thus the approach proposed here
> would not necessarily work. Thus seeing a more concrete example could
help,
> me at least :-)
>
>
>
>>
>> This approach requires many more classes and could be more complex to
>> configure.
>
>
> Well, if it will help addressing some advanced scenarios or make it
simpler
> to deal with UT/BT/etc in a single uniform way then it would be
> justifiable...The thing I like about the approach I've employed for
dealing
> with UTokens is that it is IMHO very simple and straightforward,
especially
> in the policy-first case. It is up to the interceptor which creates a
> Subject to interact with a 3rd party AuthenticationService (ex, something
> that has been initially tested with JBoss SecuritySystem), essentially, in
> your terms, it is this custom interceptor which acts as an
> 'AuthenticationStrategy', every other custom interceptor just implements
its
> own strategy.
>
> Note, I'm not saying this solution is adequate for all the cases but I
> think it works for cases where UTs are involved, possibly encrypted, with
> plain or digested passwords. But personally I'd also welcome a more
thorough
> solution/framework and looks like you have all the experience for driving
it
> forward :-). I'm not ready to commit to working on this framework but
> depending on how things go and what requirements will be there I may be
able
> to start contributing and helping with implementing it
>
>
>> I have not thoroughly been over what the default SecurityProfile
>> evaluator should be like nor do I know what concrete implementations of
>> AbstractSecurityContextProvidingInterceptor should be provided. What I
>> feel
>> to be the three most common interceptor instances are listed in the class
>> diagram. As for the default SecurityProfileChooser, I initially suggest
>> that it simply allows the user to enable/disable no security, TLS, BST,
>> and
>> UT while allowing the end user to configure the desired precedence of
each
>> profile over the other.
>>
>> This approach can easily work with Spring Security as an
>> AuthenticationService implementation.
>>
>>
> sounds great indeed.
>
> thanks, Sergey
>
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Wednesday, April 21, 2010 5:47 PM
>> To: Daniel Kulp
>> Cc: dev@cxf.apache.org
>> Subject: Re: Using WS-Security UsernameToken to authenticate users and
>> populate SecurityContexts
>>
>> I added a system test for a policy first case and refactored few bits
>> along
>> the way, as well as closed [1] as 'Wont fix', at least for now.
>>
>> I've just updated UsernameTokenInterceptor[1] so that a (WSS4J) principal
>> can be created directly if a message property disabling the validation of
>> passwords has been set.
>>
>> This property can be set as a jaxws contextual property in which case
>> interceptors further in the chain will be able to get the
>> (unauthenticated)
>> Principal, validate it, and set a SecurityContext as needed.
>>
>> Another approach used in the system test is to write a custom
>> interceptor[3]
>> extending UsernameTokenInterceptor and disable the validation from there.
>> This custom interceptor is currently being registered by setting a bus
>> property, see [4]. Note that a jaxws endpoint adds
>> SimpleAuthorizationInterceptor only and has no callbacks registered.
>>
>> See [5] for more details.
>>
>> It looks quite reasonable to me at the moment, perhaps there could be a
>> simpler way to register custom interceptors.
>>
>> Dan, you've mentioned the fact you were planning to refactor some of the
>> policy interceptors so that WSS4JInterceptor is not used for
UsernameToken
>> processing at all. I'd appreciate if you could look into this refactoring
>> yourself, there could be some subtleties there I'm not aware of. Also,
>> personally I'd prefer registering a noop processor with WSS4J rather
>> adding
>> a flag to WSS4J, perhaps this noop processor can be used for handling
>> other
>> types of tokens, using an approach similar to the one taken by
>> UsernameTokenInterceptor, unless yourself, David V, others have something
>> else in mind...
>>
>> cheers, Sergey
>>
>> [1] https://issues.apache.org/jira/browse/WSS-229
>> [2]
>>
>>
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
>> pache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
>> [3]
>>
>>
http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
>>
g/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java<h
ttp://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%
0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java
>
>> [4]
>>
>>
http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
>>
g/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml<http
://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%0Ag
/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml>
>> [5] http://svn.apache.org/viewvc?rev=936521&view=rev
>>
>>
>> On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin
>> <sb...@gmail.com>wrote:
>>
>> > Hi
>> >
>> > I've added an initial patch for addressing a policy-first case, see
[1].
>> > It's a patch because it depends on another one I submitted to WSS4J
[2].
>> > Both patches need more work (tests, etc) but I'd just like to initiate
a
>> > discussion/review.
>> >
>> > The idea behind [1] is quite similar to the one used in supporting a
>> > java-first case, where a custom interceptor extends an
>> > AbstractWSS4JSecurityContextPr
>> > oviding interceptor. But is is much simpler in [1] where
>> > UsernameTokenProcessor may be optionally extended and its createSubject
>> > method be overridden. Provided [2] gets applied then a subclass will
>> just
>> > have a property set disabling the (WSS4J) validation of passwords and
>> will
>> > do its own validation in createSubject method.
>> >
>> > This is really all what will be needed in simple cases, where a
>> > DefaultSecurityContext will do, but optionally, createSecurityContext
>> can
>> > be overridden too.
>> >
>> > A user would need to set a bus property
>> > "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a
>> custom
>> > interceptor which will indicate to the WSSecurityPolicyLoader that a
>> custom
>> > UsernameTokenProcessor subclass will need to be loaded.
>> >
>> > Similar approach can be employed for handling other types of tokens.
>> >
>> > cheers, Sergey
>> >
>> > [1] https://issues.apache.org/jira/browse/CXF-2754
>> > [2] https://issues.apache.org/jira/browse/WSS-229
>> >
>> >
>> > On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin
>> <sb...@gmail.com>wrote:
>> >
>> >> Just realized I did not CC tp dev when replying to Dan the other day :
>> >>
>> >> Hi Dan
>> >>
>> >>
>> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>> >>
>> >>>
>> >>> My main "concern" with the implementation of this is that it's done
as
>> a
>> >>> direct subclass of the WSS4JInInterceptor and thus not really usable
>> by
>> >>> the
>> >>> policy based endpoints as those interceptors subclass
>> WSS4JInInterceptor
>> >>> as
>> >>> well.
>> >>>
>> >>> I think the better approach may be to add a flag to wss4j (I can help
>> >>> commit
>> >>> changes there if needed) to have it not do any UserName token
>> processing
>> >>> at
>> >>> all. (aside: this may be doable without changes to wss4j by
>> >>> registering our
>> >>> own "do nothing processor") Then, have another interceptor that
>> runs
>> >>> after
>> >>> the WSS4JInInterceptor that would actually handle the UsernameToken
>> and
>> >>> verify
>> >>> anything it needs and such.
>> >>>
>> >>
>> >> This sounds like a very good idea, I agree the proposed approach won't
>> do
>> >> for the cases where policies drive the
>> >> creation of interceptors.
>> >>
>> >> Having said that, I think the abstract utility interceptor extending
>> >> WSS4JInInterceptor
>> >> may still be used in cases where users start from manually configuring
>> >> jaxws endpoints. In these cases they'd need to
>> >> list up to 3 interceptors (the one which extends
>> >> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if
>> the
>> >> authorization is needed plus may be a SAAJ one) but otherwise, when
say
>> a
>> >> clear text password has been encrypted, they'd still need to specify
>> >> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
>> >> UsernameTokenInterceptor, etc.
>> >>
>> >> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit
>> complicated
>> >> due to the fact it blocks the WSS4J digest checks and thus also
creates
>> a
>> >> security engine per every request, but it all will be gone in due
>> time...
>> >>
>> >>
>> >>>
>> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
>> >>> There is
>> >>> currently some duplicated code between the
>> PolicyBasedWSS4JIinInterceptor
>> >>> and
>> >>> the new UsernameTokenInterceptor that could be eliminated by having
>> the
>> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
>> delegate
>> >>> that
>> >>> completely to the UsernameTokenInterceptor.
>> >>>
>> >>
>> >> What I will do is I will experiment with the test you added (thanks
>> :-))
>> >> and see how UsernameTokenInterceptor can be refactored
>> >> so that a subclass can get an easy access to password, nonce, etc. I
>> think
>> >> I will need to come up with a contextual property so that a custom
>> >> UsernameTokenInterceptor can be installed if needed. Or may be
>> >> UsernameTokenInterceptor can store the details in a message to be
later
>> >> retrieved and processed for creating SecurityContext - but I'm not
sure
>> >> about it just yet.
>> >>
>> >>
>> >>>
>> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
>> >>> encryption/signature stuff and then let the authorization validations
>> >>> stuff to
>> >>> later interceptors. That would include things like key validation
>> >>> checking
>> >>> and stuff as well. Probably SAML token validation as well.
>> >>>
>> >>>
>> >> sounds good
>> >>
>> >> cheers, Sergey
>> >>
>> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>> >>
>> >>>
>> >>> My main "concern" with the implementation of this is that it's done
as
>> a
>> >>> direct subclass of the WSS4JInInterceptor and thus not really usable
>> by
>> >>> the
>> >>> policy based endpoints as those interceptors subclass
>> WSS4JInInterceptor
>> >>> as
>> >>> well.
>> >>>
>> >>> I think the better approach may be to add a flag to wss4j (I can help
>> >>> commit
>> >>> changes there if needed) to have it not do any UserName token
>> processing
>> >>> at
>> >>> all. (aside: this may be doable without changes to wss4j by
>> >>> registering our
>> >>> own "do nothing processor") Then, have another interceptor that
>> runs
>> >>> after
>> >>> the WSS4JInInterceptor that would actually handle the UsernameToken
>> and
>> >>> verify
>> >>> anything it needs and such.
>> >>>
>> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
>> >>> There is
>> >>> currently some duplicated code between the
>> PolicyBasedWSS4JIinInterceptor
>> >>> and
>> >>> the new UsernameTokenInterceptor that could be eliminated by having
>> the
>> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
>> delegate
>> >>> that
>> >>> completely to the UsernameTokenInterceptor.
>> >>>
>> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
>> >>> encryption/signature stuff and then let the authorization validations
>> >>> stuff to
>> >>> later interceptors. That would include things like key validation
>> >>> checking
>> >>> and stuff as well. Probably SAML token validation as well.
>> >>>
>> >>> Dan
>> >>>
>> >>>
>> >>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
>> >>> > Hi David
>> >>> >
>> >>> > thanks for the comments...
>> >>> >
>> >>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
>> >>> wrote:
>> >>> > > Sergey,
>> >>> > >
>> >>> > > I think this type of functionality would be very useful to a
>> number
>> >>> of
>> >>> > > folks. I have built two similar capabilities for clients very
>> >>> recently
>> >>> > > using CXF and Spring Security. Based on the code provided below,
>> I
>> >>> have
>> >>> > > several points that I would like to see addressed in a solution.
>> >>> > >
>> >>> > > 1) Architecture to support more than just UsernameTokens. I have
>> >>> worked
>> >>> > > with systems that need to authenticate a user using
>> UsernameTokens,
>> >>> > > BinarySecurityTokens, SAML Assertions, and a combination of more
>> than
>> >>> one
>> >>> > > of
>> >>> > > these at a time.
>> >>> >
>> >>> > Supporting UsernameTokens is the initial requirement. At the moment
>> I
>> >>> do
>> >>> > not even know how BinarySecurityTokens or SAML Assertions are
>> >>> > processed/validated in CXF or WSS4J.
>> >>> >
>> >>> > > For the most part, WSS4J simply validates the structural
>> >>> > > details of security. That is, signature validity, trust chaining
>> of
>> >>> > > digital
>> >>> > > certificates, etc. As Glen pointed out with his reference to
>> >>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
>> >>> performs
>> >>> > > its
>> >>> > > own password checking (authentication). Unfortunately, WSS4J
>> doesn't
>> >>> > > provide hooks for authenticating other forms of credentials that
I
>> >>> have
>> >>> > > listed above (I don't consider trust to be equivalent to
>> >>> authentication).
>> >>> > > It would be best if the authentication interface supported
>> multiple
>> >>> > > credential types and allowed for authentication to be performed
in
>> a
>> >>> > > single location in the same manner every time (not sometimes in
>> the
>> >>> > > WSS4J callback and sometimes in another interceptor for non-UT
>> based
>> >>> > > credentials).
>> >>> >
>> >>> > Makes sense. Assuming it is WSS4J which validates (the structure
of)
>> >>> > BinarySecurityTokens then
>> >>> AbstractWSS4JSecurityContextProvidingInterceptor
>> >>> > can also implement a processor for BinarySecurityTokens and
delegate
>> to
>> >>> > subclass to authenticate and setup a subject. Some extra methods
>> will
>> >>> need
>> >>> > to be added, to be optionally overridden.
>> >>> >
>> >>> > If it is not only WSS4J which is involved then perhaps another
>> option
>> >>> is to
>> >>> > store (from WSS4J callback handler, etc) relevant details such
>> username
>> >>> > token details, etc to be acted upon by other interceptors.
>> >>> >
>> >>> > > That
>> >>> > > last bit there means disabling WSS4J's password authentication
>> since
>> >>> it
>> >>> > > gets
>> >>> > > in the way of doing it later in our own interceptor.
>> >>> >
>> >>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
>> >>> > implementing a simplified UsernameTokenProcessor
>> >>> >
>> >>> > > 2) Allow for end-user flexibility in choosing the credentials
they
>> >>> want
>> >>> > > to authenticate. For instance, each user is going to have their
>> own
>> >>> > > security profiles and authentication requirements. For instance,
>> a
>> >>> > > message contains a UT for a portal user and a digital signature
>> from
>> >>> the
>> >>> > > portal (I know using
>> >>> > > a SAML Assertion would be better here, but people still do it
this
>> >>> way).
>> >>> > > Each organization will have different requirements as to which
>> >>> > > credentials get authenticated and what needs to end up in the
>> >>> security
>> >>> > > context.
>> >>> >
>> >>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor
>> subclasses
>> >>> > should be able to do it, for username tokens and other tokens later
>> on.
>> >>> >
>> >>> > > 3) Decouple the authentication interface from WSS4J. What is
>> passed
>> >>> in
>> >>> > > needs to be abstracted enough that it can work with other
>> WS-Security
>> >>> > > libraries as well.
>> >>> >
>> >>> > the only WSS4J class which is leaked at the moment is
>> >>> WSSecurityException.
>> >>> > Perhaps we can come up later on with a different more generic
>> approach
>> >>> > which does not depend on WSS4J at all. As Dan indicated, in some
>> cases
>> >>> > WSS4JInInterceptor is not even used, so that case will need to be
>> >>> > addressed. Experimenting wuth binary tokens might help with
>> identifying
>> >>> > another solution.
>> >>> >
>> >>> > > 4) It would be nice to be able to perform authorization using
>> >>> something
>> >>> > > like
>> >>> > > Spring Security at the service operation level. With a POJO or
>> >>> JAX-WS
>> >>> > > based
>> >>> > > service, one can just use Spring Security's method interceptor to
>> >>> provide
>> >>> > > such security; however, in situations where one only has a WSDL
>> based
>> >>> > > service or a provider style service, a method interceptor can't
be
>> >>> used.
>> >>> > >
>> >>> > > It
>> >>> > >
>> >>> > > would be nice to provide a hook into Spring Security to allow
>> >>> end-users
>> >>> > > to specify role based authorization policy based on a combination
>> of
>> >>> > > interface,
>> >>> > > instance, and operation names. It seems like your
>> >>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor
>> are
>> >>> > > looking in this direction, but I think it would be best if we can
>> >>> stand
>> >>> > > on the shoulders of the Spring Security giant as much as possible
>> so
>> >>> > > that we can take advantage of their rich authorization manager,
>> >>> voter,
>> >>> > > XML
>> >>> > > configuration
>> >>> > > capabilities.
>> >>> >
>> >>> > Not sure what to say here yet. But I think non-Spring users should
>> be
>> >>> taken
>> >>> > care of too. Or when simpler cases are dealt with then perhaps
>> there's
>> >>> no
>> >>> > need to bring in Spring security. Perhaps the utility authorization
>> >>> > interceptors should just not be used when Spring Security is
>> preferred
>> >>> ?
>> >>> >
>> >>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
>> >>> CXF-BC
>> >>> > > currently has a limited capability to select the credentials to
>> >>> > > authenticate
>> >>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
>> >>> delegates
>> >>> > > authentication to the JBI container through a ServiceMix
>> components
>> >>> > > authentication service abstraction of JAAS. Whatever solution we
>> >>> have
>> >>> > > for 1
>> >>> > > and 2 would help out the component if the ServiceMix
>> authentication
>> >>> > > service abstraction could be wired up in lieu of whatever we
>> provide
>> >>> out
>> >>> > > of the box.
>> >>> >
>> >>> > I'm not planning to contribute to ServiceMix. I agree though that
an
>> >>> ideal
>> >>> > solution will meet multiple requirements
>> >>> >
>> >>> > thanks, Sergey
>> >>> >
>> >>> > > -----Original Message-----
>> >>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> >>> > > Sent: Wednesday, April 07, 2010 10:11 AM
>> >>> > > To: dev@cxf.apache.org
>> >>> > > Subject: Using WS-Security UsernameToken to authenticate users
and
>> >>> > > populate SecurityContexts
>> >>> > >
>> >>> > > Hi
>> >>> > >
>> >>> > > I've been looking recently at extending the CXF WS-Security
>> component
>> >>> > > such that a current UsernameToken could be used by custom
>> >>> interceptors
>> >>> > > to authenticate a user with the external security systems and, if
>> >>> > > possible, provide enough information for CXF to populate a
>> >>> > > SecurityContext [1] to be used later on for
>> >>> > > authorization decisions.
>> >>> > >
>> >>> > > Here is the approach I've taken so far.
>> >>> > > A custom interceptor extends
>> >>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
>> >>> method
>> >>> > > it overrides is
>> >>> > >
>> >>> > > abstract Subject createSubject(String name, String password,
>> boolean
>> >>> > > isDigest,
>> >>> > >
>> >>> > > String nonce,
>> >>> > > String created) throws
>> >>> > >
>> >>> > > WSSecurityException;
>> >>> > >
>> >>> > >
>> >>> > > For example, see [3].
>> >>> > >
>> >>> > > The idea here is that a custom interceptor interfaces whichever
>> way
>> >>> it
>> >>> > > needs
>> >>> > > to with the external system and populates a Subject following
this
>> >>> simple
>> >>> > > rule : first Subject principal is the current user (identified by
>> a
>> >>> > > 'name' argument), followed by one or more Groups this user is a
>> >>> member
>> >>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use
this
>> >>> > > Subject to provide a functional SecurityContext instance.
>> >>> > >
>> >>> > > This is the first part, next is how to utilize a SecurityContext
>> and
>> >>> get
>> >>> > > the
>> >>> > > expected roles associated one way or the other with a current
>> method
>> >>> to
>> >>> > > be invoked. There's a number of usual options available here,
>> perhaps
>> >>> > > even SpringSecurity can be used now that SecurityContext is
>> >>> available,
>> >>> > > or application code or other custom CXF interceptor can check the
>> >>> known
>> >>> > > roles against SecurityContext.
>> >>> > >
>> >>> > > I've also added AbstractAuthorizingInInterceptor interceptor
which
>> >>> custom
>> >>> > > interceptors can override and return a list of expected roles
>> given
>> a
>> >>> > > (service) Method to be invoked upon,
>> AbstractAuthorizingInInterceptor
>> >>> > > will then ask available SecurityContext to match the roles; one
>> >>> concrete
>> >>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
>> injected
>> >>> > > with a
>> >>> > > method specific or class (applying to all methods) roles. Another
>> >>> > > implementation which I will likely add later on will be injected
>> with
>> >>> a
>> >>> > > name
>> >>> > > of annotation such as RolesAlloved and it will introspect a
method
>> >>> and
>> >>> > > its class.
>> >>> > >
>> >>> > > Note that I haven't looked into the case when a policy runtimes
>> adds
>> >>> the
>> >>> > > interceptors yet (as opposed to interceptors being configured
form
>> >>> > > Spring/programmatically). I think an optional contextual property
>> >>> will
>> >>> > > need to be setup in such cases for users be able to indicate that
>> say
>> >>> an
>> >>> > > interceptor such as [3] has to be used as opposed to
>> >>> WSS4JInInterceptor,
>> >>> > > etc.
>> >>> > >
>> >>> > > I'm going to validate this approach with JBoss CXF. If you have
>> any
>> >>> > > comments
>> >>> > > then please let me know.
>> >>> > >
>> >>> > > I think we may have a simpler alternative eventually to the way
>> >>> > > authorization decisions are made. [1]-[3] is specific to
>> ws-security,
>> >>> but
>> >>> > > [4]-[5] is not
>> >>> > >
>> >>> > > cheers, Sergey
>> >>> > >
>> >>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
>> >>> > > [2]
>> >>> > >
>> >>> > >
>> >>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
>> >>> > > g/a
>> >>> > >
>> >>> > >
>> >>>
>> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
>> >>> > > tor<
>> >>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
>> >>> > >
>> >>>
>> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
>> >>> > > ngInterceptor> .java
>> >>> > > [3]
>> >>> > >
>> >>> > >
>> >>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
>> >>> > > g/a
>> >>> > >
>> >>>
>> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
>> >>> > > /
>> >>>
>> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
>> >>> > >
pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
>> >>> [4]
>> >>> > >
>> >>> > >
>> >>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>> >>> > > e/c
>> >>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
>> >>> http://svn
>> >>> > > .
>> >>>
>> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
>> >>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
>> >>> > >
>> >>> > >
>> >>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>> >>> > > e/c
>> >>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
>> >>> http://svn.apa
>> >>> > >
>> >>>
>> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
>> >>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>> >>>
>> >>> --
>> >>> Daniel Kulp
>> >>> dkulp@apache.org
>> >>> http://dankulp.com/blog
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
I've been thinking a bit more about your idea. As I said it looks
interesting but what have not quite understood is how you're planning to
hide the WSS4J specifics from the interceptors further in the chain.
Example, the Principal that WSS4J UT processor returns has an info about the
type of password (digest or not) which is made available to
(Abstract)WSS4J(SecurityContext)Interceptor or UsernameTokenInterceptor
subclasses without them having to be aware of WSS4J. Both interceptors can
make the actual Principal available to other interceptors but it is just a
Principal interface...
So I'm presuming, without seeing your diagrams, WSS4JInInterceptor would
need to process the WWS4J response and store all the "Credential" objects in
a current Message, alongside with properties specifying the types of these
Credentials. Authenticating interceptors would then check a type, cast a
given Credential to say "UTCredential" (with all the details like password
type, etc) or BinaryTokenCredential, etc... and do whatever they need to.
This could indeed present an option to the subclassing one. As I said, IMHO
the latter one is good enough on its own when we have a UT only to deal with
but I'm positive about seeing a more comprehensive approach being explored
and realized
As I said, having some system test (as a patch for ex) would help to see the
whole picture you're having in mind.
cheers, Sergey
On Thu, Apr 22, 2010 at 10:18 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi
>
> On Thu, Apr 22, 2010 at 9:14 PM, David Valeri <dv...@apache.org> wrote:
>
>> Attached are some quick and dirty class/seq diagrams that outline a
>> slightly
>> different approach to determining which credentials to authenticate,
>> choosing how to extract them, and then actually performing the
>> authentication.
>>
>>
> I do not see the attachments, perhaps you may want to attach them to the
> actual JIRA
> (https://issues.apache.org/jira/browse/CXF-2754)
>
>
>> This approach would still require configuring your customized UT Processor
>> in WSS4J in order to disable WSS4Js clumsy authentication system but moves
>> the work of creating the SecurityContext and JAAS subject out of the WSS4J
>> interceptors and into generic authentication framework. It looks like
>> WSS4JInInterceptor simply looks for the first principal it finds in the
>> WSS4J results and sends that on its way. When multiple tokens appear in a
>> message, this approach may not always grab the one the application really
>> requires.
>>
>>
> OK. I think that for a java-first case utilizing
> AbstractSecurityContextProvidingInterceptor
> would ensure a Principal associated with a Subject is the one obtained from
> a UTProcessor.
> Ditto for a policy-first case where a UsernameTakenInterceptor subclass is
> used.
>
>
>> This approach works after the WSS4J security processing completes and
>> examines the results from WSS4J, or another security framework if we ever
>> use one, and determines which profile is in effect. A delegate
>> interceptor
>> is then called to extract the correct user credentials from the message
>> and
>> perform any additional validation that is needed for a given profile. The
>> extracted credentials are then passed to an AuthenticationStrategy to
>> perform the actual authentication. The AuthenticationService would return
>> something like a JAAS Subject that is then used to create the CXF
>> SecurityContext. As you can see, the "Credentials" concept is pretty
>> vague
>> as there are many different types of credentials out there. I feel that
>> the
>> most common two are X509 certificates and Username Tokens.
>>
>
> Sounds like you're proposing a serious and generic solution which is great.
> But I'd be great if you could do a bit of prototyping so that we can see
> how things (like configuration, etc) actually look like ?
> I believe one of your main concerns is that a given request may contain
> multiple "Credentials" and thus the approach proposed here
> would not necessarily work. Thus seeing a more concrete example could help,
> me at least :-)
>
>
>
>>
>> This approach requires many more classes and could be more complex to
>> configure.
>
>
> Well, if it will help addressing some advanced scenarios or make it simpler
> to deal with UT/BT/etc in a single uniform way then it would be
> justifiable...The thing I like about the approach I've employed for dealing
> with UTokens is that it is IMHO very simple and straightforward, especially
> in the policy-first case. It is up to the interceptor which creates a
> Subject to interact with a 3rd party AuthenticationService (ex, something
> that has been initially tested with JBoss SecuritySystem), essentially, in
> your terms, it is this custom interceptor which acts as an
> 'AuthenticationStrategy', every other custom interceptor just implements its
> own strategy.
>
> Note, I'm not saying this solution is adequate for all the cases but I
> think it works for cases where UTs are involved, possibly encrypted, with
> plain or digested passwords. But personally I'd also welcome a more thorough
> solution/framework and looks like you have all the experience for driving it
> forward :-). I'm not ready to commit to working on this framework but
> depending on how things go and what requirements will be there I may be able
> to start contributing and helping with implementing it
>
>
>> I have not thoroughly been over what the default SecurityProfile
>> evaluator should be like nor do I know what concrete implementations of
>> AbstractSecurityContextProvidingInterceptor should be provided. What I
>> feel
>> to be the three most common interceptor instances are listed in the class
>> diagram. As for the default SecurityProfileChooser, I initially suggest
>> that it simply allows the user to enable/disable no security, TLS, BST,
>> and
>> UT while allowing the end user to configure the desired precedence of each
>> profile over the other.
>>
>> This approach can easily work with Spring Security as an
>> AuthenticationService implementation.
>>
>>
> sounds great indeed.
>
> thanks, Sergey
>
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Wednesday, April 21, 2010 5:47 PM
>> To: Daniel Kulp
>> Cc: dev@cxf.apache.org
>> Subject: Re: Using WS-Security UsernameToken to authenticate users and
>> populate SecurityContexts
>>
>> I added a system test for a policy first case and refactored few bits
>> along
>> the way, as well as closed [1] as 'Wont fix', at least for now.
>>
>> I've just updated UsernameTokenInterceptor[1] so that a (WSS4J) principal
>> can be created directly if a message property disabling the validation of
>> passwords has been set.
>>
>> This property can be set as a jaxws contextual property in which case
>> interceptors further in the chain will be able to get the
>> (unauthenticated)
>> Principal, validate it, and set a SecurityContext as needed.
>>
>> Another approach used in the system test is to write a custom
>> interceptor[3]
>> extending UsernameTokenInterceptor and disable the validation from there.
>> This custom interceptor is currently being registered by setting a bus
>> property, see [4]. Note that a jaxws endpoint adds
>> SimpleAuthorizationInterceptor only and has no callbacks registered.
>>
>> See [5] for more details.
>>
>> It looks quite reasonable to me at the moment, perhaps there could be a
>> simpler way to register custom interceptors.
>>
>> Dan, you've mentioned the fact you were planning to refactor some of the
>> policy interceptors so that WSS4JInterceptor is not used for UsernameToken
>> processing at all. I'd appreciate if you could look into this refactoring
>> yourself, there could be some subtleties there I'm not aware of. Also,
>> personally I'd prefer registering a noop processor with WSS4J rather
>> adding
>> a flag to WSS4J, perhaps this noop processor can be used for handling
>> other
>> types of tokens, using an approach similar to the one taken by
>> UsernameTokenInterceptor, unless yourself, David V, others have something
>> else in mind...
>>
>> cheers, Sergey
>>
>> [1] https://issues.apache.org/jira/browse/WSS-229
>> [2]
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
>> pache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
>> [3]
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
>> g/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java<http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java>
>> [4]
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
>> g/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml<http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%0Ag/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml>
>> [5] http://svn.apache.org/viewvc?rev=936521&view=rev
>>
>>
>> On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin
>> <sb...@gmail.com>wrote:
>>
>> > Hi
>> >
>> > I've added an initial patch for addressing a policy-first case, see [1].
>> > It's a patch because it depends on another one I submitted to WSS4J [2].
>> > Both patches need more work (tests, etc) but I'd just like to initiate a
>> > discussion/review.
>> >
>> > The idea behind [1] is quite similar to the one used in supporting a
>> > java-first case, where a custom interceptor extends an
>> > AbstractWSS4JSecurityContextPr
>> > oviding interceptor. But is is much simpler in [1] where
>> > UsernameTokenProcessor may be optionally extended and its createSubject
>> > method be overridden. Provided [2] gets applied then a subclass will
>> just
>> > have a property set disabling the (WSS4J) validation of passwords and
>> will
>> > do its own validation in createSubject method.
>> >
>> > This is really all what will be needed in simple cases, where a
>> > DefaultSecurityContext will do, but optionally, createSecurityContext
>> can
>> > be overridden too.
>> >
>> > A user would need to set a bus property
>> > "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a
>> custom
>> > interceptor which will indicate to the WSSecurityPolicyLoader that a
>> custom
>> > UsernameTokenProcessor subclass will need to be loaded.
>> >
>> > Similar approach can be employed for handling other types of tokens.
>> >
>> > cheers, Sergey
>> >
>> > [1] https://issues.apache.org/jira/browse/CXF-2754
>> > [2] https://issues.apache.org/jira/browse/WSS-229
>> >
>> >
>> > On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin
>> <sb...@gmail.com>wrote:
>> >
>> >> Just realized I did not CC tp dev when replying to Dan the other day :
>> >>
>> >> Hi Dan
>> >>
>> >>
>> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>> >>
>> >>>
>> >>> My main "concern" with the implementation of this is that it's done as
>> a
>> >>> direct subclass of the WSS4JInInterceptor and thus not really usable
>> by
>> >>> the
>> >>> policy based endpoints as those interceptors subclass
>> WSS4JInInterceptor
>> >>> as
>> >>> well.
>> >>>
>> >>> I think the better approach may be to add a flag to wss4j (I can help
>> >>> commit
>> >>> changes there if needed) to have it not do any UserName token
>> processing
>> >>> at
>> >>> all. (aside: this may be doable without changes to wss4j by
>> >>> registering our
>> >>> own "do nothing processor") Then, have another interceptor that
>> runs
>> >>> after
>> >>> the WSS4JInInterceptor that would actually handle the UsernameToken
>> and
>> >>> verify
>> >>> anything it needs and such.
>> >>>
>> >>
>> >> This sounds like a very good idea, I agree the proposed approach won't
>> do
>> >> for the cases where policies drive the
>> >> creation of interceptors.
>> >>
>> >> Having said that, I think the abstract utility interceptor extending
>> >> WSS4JInInterceptor
>> >> may still be used in cases where users start from manually configuring
>> >> jaxws endpoints. In these cases they'd need to
>> >> list up to 3 interceptors (the one which extends
>> >> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if
>> the
>> >> authorization is needed plus may be a SAAJ one) but otherwise, when say
>> a
>> >> clear text password has been encrypted, they'd still need to specify
>> >> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
>> >> UsernameTokenInterceptor, etc.
>> >>
>> >> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit
>> complicated
>> >> due to the fact it blocks the WSS4J digest checks and thus also creates
>> a
>> >> security engine per every request, but it all will be gone in due
>> time...
>> >>
>> >>
>> >>>
>> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
>> >>> There is
>> >>> currently some duplicated code between the
>> PolicyBasedWSS4JIinInterceptor
>> >>> and
>> >>> the new UsernameTokenInterceptor that could be eliminated by having
>> the
>> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
>> delegate
>> >>> that
>> >>> completely to the UsernameTokenInterceptor.
>> >>>
>> >>
>> >> What I will do is I will experiment with the test you added (thanks
>> :-))
>> >> and see how UsernameTokenInterceptor can be refactored
>> >> so that a subclass can get an easy access to password, nonce, etc. I
>> think
>> >> I will need to come up with a contextual property so that a custom
>> >> UsernameTokenInterceptor can be installed if needed. Or may be
>> >> UsernameTokenInterceptor can store the details in a message to be later
>> >> retrieved and processed for creating SecurityContext - but I'm not sure
>> >> about it just yet.
>> >>
>> >>
>> >>>
>> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
>> >>> encryption/signature stuff and then let the authorization validations
>> >>> stuff to
>> >>> later interceptors. That would include things like key validation
>> >>> checking
>> >>> and stuff as well. Probably SAML token validation as well.
>> >>>
>> >>>
>> >> sounds good
>> >>
>> >> cheers, Sergey
>> >>
>> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>> >>
>> >>>
>> >>> My main "concern" with the implementation of this is that it's done as
>> a
>> >>> direct subclass of the WSS4JInInterceptor and thus not really usable
>> by
>> >>> the
>> >>> policy based endpoints as those interceptors subclass
>> WSS4JInInterceptor
>> >>> as
>> >>> well.
>> >>>
>> >>> I think the better approach may be to add a flag to wss4j (I can help
>> >>> commit
>> >>> changes there if needed) to have it not do any UserName token
>> processing
>> >>> at
>> >>> all. (aside: this may be doable without changes to wss4j by
>> >>> registering our
>> >>> own "do nothing processor") Then, have another interceptor that
>> runs
>> >>> after
>> >>> the WSS4JInInterceptor that would actually handle the UsernameToken
>> and
>> >>> verify
>> >>> anything it needs and such.
>> >>>
>> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
>> >>> There is
>> >>> currently some duplicated code between the
>> PolicyBasedWSS4JIinInterceptor
>> >>> and
>> >>> the new UsernameTokenInterceptor that could be eliminated by having
>> the
>> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
>> delegate
>> >>> that
>> >>> completely to the UsernameTokenInterceptor.
>> >>>
>> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
>> >>> encryption/signature stuff and then let the authorization validations
>> >>> stuff to
>> >>> later interceptors. That would include things like key validation
>> >>> checking
>> >>> and stuff as well. Probably SAML token validation as well.
>> >>>
>> >>> Dan
>> >>>
>> >>>
>> >>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
>> >>> > Hi David
>> >>> >
>> >>> > thanks for the comments...
>> >>> >
>> >>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
>> >>> wrote:
>> >>> > > Sergey,
>> >>> > >
>> >>> > > I think this type of functionality would be very useful to a
>> number
>> >>> of
>> >>> > > folks. I have built two similar capabilities for clients very
>> >>> recently
>> >>> > > using CXF and Spring Security. Based on the code provided below,
>> I
>> >>> have
>> >>> > > several points that I would like to see addressed in a solution.
>> >>> > >
>> >>> > > 1) Architecture to support more than just UsernameTokens. I have
>> >>> worked
>> >>> > > with systems that need to authenticate a user using
>> UsernameTokens,
>> >>> > > BinarySecurityTokens, SAML Assertions, and a combination of more
>> than
>> >>> one
>> >>> > > of
>> >>> > > these at a time.
>> >>> >
>> >>> > Supporting UsernameTokens is the initial requirement. At the moment
>> I
>> >>> do
>> >>> > not even know how BinarySecurityTokens or SAML Assertions are
>> >>> > processed/validated in CXF or WSS4J.
>> >>> >
>> >>> > > For the most part, WSS4J simply validates the structural
>> >>> > > details of security. That is, signature validity, trust chaining
>> of
>> >>> > > digital
>> >>> > > certificates, etc. As Glen pointed out with his reference to
>> >>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
>> >>> performs
>> >>> > > its
>> >>> > > own password checking (authentication). Unfortunately, WSS4J
>> doesn't
>> >>> > > provide hooks for authenticating other forms of credentials that I
>> >>> have
>> >>> > > listed above (I don't consider trust to be equivalent to
>> >>> authentication).
>> >>> > > It would be best if the authentication interface supported
>> multiple
>> >>> > > credential types and allowed for authentication to be performed in
>> a
>> >>> > > single location in the same manner every time (not sometimes in
>> the
>> >>> > > WSS4J callback and sometimes in another interceptor for non-UT
>> based
>> >>> > > credentials).
>> >>> >
>> >>> > Makes sense. Assuming it is WSS4J which validates (the structure of)
>> >>> > BinarySecurityTokens then
>> >>> AbstractWSS4JSecurityContextProvidingInterceptor
>> >>> > can also implement a processor for BinarySecurityTokens and delegate
>> to
>> >>> > subclass to authenticate and setup a subject. Some extra methods
>> will
>> >>> need
>> >>> > to be added, to be optionally overridden.
>> >>> >
>> >>> > If it is not only WSS4J which is involved then perhaps another
>> option
>> >>> is to
>> >>> > store (from WSS4J callback handler, etc) relevant details such
>> username
>> >>> > token details, etc to be acted upon by other interceptors.
>> >>> >
>> >>> > > That
>> >>> > > last bit there means disabling WSS4J's password authentication
>> since
>> >>> it
>> >>> > > gets
>> >>> > > in the way of doing it later in our own interceptor.
>> >>> >
>> >>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
>> >>> > implementing a simplified UsernameTokenProcessor
>> >>> >
>> >>> > > 2) Allow for end-user flexibility in choosing the credentials they
>> >>> want
>> >>> > > to authenticate. For instance, each user is going to have their
>> own
>> >>> > > security profiles and authentication requirements. For instance,
>> a
>> >>> > > message contains a UT for a portal user and a digital signature
>> from
>> >>> the
>> >>> > > portal (I know using
>> >>> > > a SAML Assertion would be better here, but people still do it this
>> >>> way).
>> >>> > > Each organization will have different requirements as to which
>> >>> > > credentials get authenticated and what needs to end up in the
>> >>> security
>> >>> > > context.
>> >>> >
>> >>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor
>> subclasses
>> >>> > should be able to do it, for username tokens and other tokens later
>> on.
>> >>> >
>> >>> > > 3) Decouple the authentication interface from WSS4J. What is
>> passed
>> >>> in
>> >>> > > needs to be abstracted enough that it can work with other
>> WS-Security
>> >>> > > libraries as well.
>> >>> >
>> >>> > the only WSS4J class which is leaked at the moment is
>> >>> WSSecurityException.
>> >>> > Perhaps we can come up later on with a different more generic
>> approach
>> >>> > which does not depend on WSS4J at all. As Dan indicated, in some
>> cases
>> >>> > WSS4JInInterceptor is not even used, so that case will need to be
>> >>> > addressed. Experimenting wuth binary tokens might help with
>> identifying
>> >>> > another solution.
>> >>> >
>> >>> > > 4) It would be nice to be able to perform authorization using
>> >>> something
>> >>> > > like
>> >>> > > Spring Security at the service operation level. With a POJO or
>> >>> JAX-WS
>> >>> > > based
>> >>> > > service, one can just use Spring Security's method interceptor to
>> >>> provide
>> >>> > > such security; however, in situations where one only has a WSDL
>> based
>> >>> > > service or a provider style service, a method interceptor can't be
>> >>> used.
>> >>> > >
>> >>> > > It
>> >>> > >
>> >>> > > would be nice to provide a hook into Spring Security to allow
>> >>> end-users
>> >>> > > to specify role based authorization policy based on a combination
>> of
>> >>> > > interface,
>> >>> > > instance, and operation names. It seems like your
>> >>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor
>> are
>> >>> > > looking in this direction, but I think it would be best if we can
>> >>> stand
>> >>> > > on the shoulders of the Spring Security giant as much as possible
>> so
>> >>> > > that we can take advantage of their rich authorization manager,
>> >>> voter,
>> >>> > > XML
>> >>> > > configuration
>> >>> > > capabilities.
>> >>> >
>> >>> > Not sure what to say here yet. But I think non-Spring users should
>> be
>> >>> taken
>> >>> > care of too. Or when simpler cases are dealt with then perhaps
>> there's
>> >>> no
>> >>> > need to bring in Spring security. Perhaps the utility authorization
>> >>> > interceptors should just not be used when Spring Security is
>> preferred
>> >>> ?
>> >>> >
>> >>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
>> >>> CXF-BC
>> >>> > > currently has a limited capability to select the credentials to
>> >>> > > authenticate
>> >>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
>> >>> delegates
>> >>> > > authentication to the JBI container through a ServiceMix
>> components
>> >>> > > authentication service abstraction of JAAS. Whatever solution we
>> >>> have
>> >>> > > for 1
>> >>> > > and 2 would help out the component if the ServiceMix
>> authentication
>> >>> > > service abstraction could be wired up in lieu of whatever we
>> provide
>> >>> out
>> >>> > > of the box.
>> >>> >
>> >>> > I'm not planning to contribute to ServiceMix. I agree though that an
>> >>> ideal
>> >>> > solution will meet multiple requirements
>> >>> >
>> >>> > thanks, Sergey
>> >>> >
>> >>> > > -----Original Message-----
>> >>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> >>> > > Sent: Wednesday, April 07, 2010 10:11 AM
>> >>> > > To: dev@cxf.apache.org
>> >>> > > Subject: Using WS-Security UsernameToken to authenticate users and
>> >>> > > populate SecurityContexts
>> >>> > >
>> >>> > > Hi
>> >>> > >
>> >>> > > I've been looking recently at extending the CXF WS-Security
>> component
>> >>> > > such that a current UsernameToken could be used by custom
>> >>> interceptors
>> >>> > > to authenticate a user with the external security systems and, if
>> >>> > > possible, provide enough information for CXF to populate a
>> >>> > > SecurityContext [1] to be used later on for
>> >>> > > authorization decisions.
>> >>> > >
>> >>> > > Here is the approach I've taken so far.
>> >>> > > A custom interceptor extends
>> >>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
>> >>> method
>> >>> > > it overrides is
>> >>> > >
>> >>> > > abstract Subject createSubject(String name, String password,
>> boolean
>> >>> > > isDigest,
>> >>> > >
>> >>> > > String nonce,
>> >>> > > String created) throws
>> >>> > >
>> >>> > > WSSecurityException;
>> >>> > >
>> >>> > >
>> >>> > > For example, see [3].
>> >>> > >
>> >>> > > The idea here is that a custom interceptor interfaces whichever
>> way
>> >>> it
>> >>> > > needs
>> >>> > > to with the external system and populates a Subject following this
>> >>> simple
>> >>> > > rule : first Subject principal is the current user (identified by
>> a
>> >>> > > 'name' argument), followed by one or more Groups this user is a
>> >>> member
>> >>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
>> >>> > > Subject to provide a functional SecurityContext instance.
>> >>> > >
>> >>> > > This is the first part, next is how to utilize a SecurityContext
>> and
>> >>> get
>> >>> > > the
>> >>> > > expected roles associated one way or the other with a current
>> method
>> >>> to
>> >>> > > be invoked. There's a number of usual options available here,
>> perhaps
>> >>> > > even SpringSecurity can be used now that SecurityContext is
>> >>> available,
>> >>> > > or application code or other custom CXF interceptor can check the
>> >>> known
>> >>> > > roles against SecurityContext.
>> >>> > >
>> >>> > > I've also added AbstractAuthorizingInInterceptor interceptor which
>> >>> custom
>> >>> > > interceptors can override and return a list of expected roles
>> given
>> a
>> >>> > > (service) Method to be invoked upon,
>> AbstractAuthorizingInInterceptor
>> >>> > > will then ask available SecurityContext to match the roles; one
>> >>> concrete
>> >>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
>> injected
>> >>> > > with a
>> >>> > > method specific or class (applying to all methods) roles. Another
>> >>> > > implementation which I will likely add later on will be injected
>> with
>> >>> a
>> >>> > > name
>> >>> > > of annotation such as RolesAlloved and it will introspect a method
>> >>> and
>> >>> > > its class.
>> >>> > >
>> >>> > > Note that I haven't looked into the case when a policy runtimes
>> adds
>> >>> the
>> >>> > > interceptors yet (as opposed to interceptors being configured form
>> >>> > > Spring/programmatically). I think an optional contextual property
>> >>> will
>> >>> > > need to be setup in such cases for users be able to indicate that
>> say
>> >>> an
>> >>> > > interceptor such as [3] has to be used as opposed to
>> >>> WSS4JInInterceptor,
>> >>> > > etc.
>> >>> > >
>> >>> > > I'm going to validate this approach with JBoss CXF. If you have
>> any
>> >>> > > comments
>> >>> > > then please let me know.
>> >>> > >
>> >>> > > I think we may have a simpler alternative eventually to the way
>> >>> > > authorization decisions are made. [1]-[3] is specific to
>> ws-security,
>> >>> but
>> >>> > > [4]-[5] is not
>> >>> > >
>> >>> > > cheers, Sergey
>> >>> > >
>> >>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
>> >>> > > [2]
>> >>> > >
>> >>> > >
>> >>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
>> >>> > > g/a
>> >>> > >
>> >>> > >
>> >>>
>> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
>> >>> > > tor<
>> >>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
>> >>> > >
>> >>>
>> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
>> >>> > > ngInterceptor> .java
>> >>> > > [3]
>> >>> > >
>> >>> > >
>> >>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
>> >>> > > g/a
>> >>> > >
>> >>>
>> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
>> >>> > > /
>> >>>
>> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
>> >>> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
>> >>> [4]
>> >>> > >
>> >>> > >
>> >>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>> >>> > > e/c
>> >>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
>> >>> http://svn
>> >>> > > .
>> >>>
>> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
>> >>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
>> >>> > >
>> >>> > >
>> >>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>> >>> > > e/c
>> >>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
>> >>> http://svn.apa
>> >>> > >
>> >>>
>> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
>> >>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>> >>>
>> >>> --
>> >>> Daniel Kulp
>> >>> dkulp@apache.org
>> >>> http://dankulp.com/blog
>> >>>
>> >>
>> >>
>> >
>>
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Thu, Apr 22, 2010 at 9:14 PM, David Valeri <dv...@apache.org> wrote:
> Attached are some quick and dirty class/seq diagrams that outline a
> slightly
> different approach to determining which credentials to authenticate,
> choosing how to extract them, and then actually performing the
> authentication.
>
>
I do not see the attachments, perhaps you may want to attach them to the
actual JIRA
(https://issues.apache.org/jira/browse/CXF-2754)
> This approach would still require configuring your customized UT Processor
> in WSS4J in order to disable WSS4Js clumsy authentication system but moves
> the work of creating the SecurityContext and JAAS subject out of the WSS4J
> interceptors and into generic authentication framework. It looks like
> WSS4JInInterceptor simply looks for the first principal it finds in the
> WSS4J results and sends that on its way. When multiple tokens appear in a
> message, this approach may not always grab the one the application really
> requires.
>
>
OK. I think that for a java-first case utilizing
AbstractSecurityContextProvidingInterceptor
would ensure a Principal associated with a Subject is the one obtained from
a UTProcessor.
Ditto for a policy-first case where a UsernameTakenInterceptor subclass is
used.
> This approach works after the WSS4J security processing completes and
> examines the results from WSS4J, or another security framework if we ever
> use one, and determines which profile is in effect. A delegate interceptor
> is then called to extract the correct user credentials from the message and
> perform any additional validation that is needed for a given profile. The
> extracted credentials are then passed to an AuthenticationStrategy to
> perform the actual authentication. The AuthenticationService would return
> something like a JAAS Subject that is then used to create the CXF
> SecurityContext. As you can see, the "Credentials" concept is pretty vague
> as there are many different types of credentials out there. I feel that
> the
> most common two are X509 certificates and Username Tokens.
>
Sounds like you're proposing a serious and generic solution which is great.
But I'd be great if you could do a bit of prototyping so that we can see how
things (like configuration, etc) actually look like ?
I believe one of your main concerns is that a given request may contain
multiple "Credentials" and thus the approach proposed here
would not necessarily work. Thus seeing a more concrete example could help,
me at least :-)
>
> This approach requires many more classes and could be more complex to
> configure.
Well, if it will help addressing some advanced scenarios or make it simpler
to deal with UT/BT/etc in a single uniform way then it would be
justifiable...The thing I like about the approach I've employed for dealing
with UTokens is that it is IMHO very simple and straightforward, especially
in the policy-first case. It is up to the interceptor which creates a
Subject to interact with a 3rd party AuthenticationService (ex, something
that has been initially tested with JBoss SecuritySystem), essentially, in
your terms, it is this custom interceptor which acts as an
'AuthenticationStrategy', every other custom interceptor just implements its
own strategy.
Note, I'm not saying this solution is adequate for all the cases but I think
it works for cases where UTs are involved, possibly encrypted, with plain or
digested passwords. But personally I'd also welcome a more thorough
solution/framework and looks like you have all the experience for driving it
forward :-). I'm not ready to commit to working on this framework but
depending on how things go and what requirements will be there I may be able
to start contributing and helping with implementing it
> I have not thoroughly been over what the default SecurityProfile
> evaluator should be like nor do I know what concrete implementations of
> AbstractSecurityContextProvidingInterceptor should be provided. What I
> feel
> to be the three most common interceptor instances are listed in the class
> diagram. As for the default SecurityProfileChooser, I initially suggest
> that it simply allows the user to enable/disable no security, TLS, BST, and
> UT while allowing the end user to configure the desired precedence of each
> profile over the other.
>
> This approach can easily work with Spring Security as an
> AuthenticationService implementation.
>
>
sounds great indeed.
thanks, Sergey
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Wednesday, April 21, 2010 5:47 PM
> To: Daniel Kulp
> Cc: dev@cxf.apache.org
> Subject: Re: Using WS-Security UsernameToken to authenticate users and
> populate SecurityContexts
>
> I added a system test for a policy first case and refactored few bits along
> the way, as well as closed [1] as 'Wont fix', at least for now.
>
> I've just updated UsernameTokenInterceptor[1] so that a (WSS4J) principal
> can be created directly if a message property disabling the validation of
> passwords has been set.
>
> This property can be set as a jaxws contextual property in which case
> interceptors further in the chain will be able to get the (unauthenticated)
> Principal, validate it, and set a SecurityContext as needed.
>
> Another approach used in the system test is to write a custom
> interceptor[3]
> extending UsernameTokenInterceptor and disable the validation from there.
> This custom interceptor is currently being registered by setting a bus
> property, see [4]. Note that a jaxws endpoint adds
> SimpleAuthorizationInterceptor only and has no callbacks registered.
>
> See [5] for more details.
>
> It looks quite reasonable to me at the moment, perhaps there could be a
> simpler way to register custom interceptors.
>
> Dan, you've mentioned the fact you were planning to refactor some of the
> policy interceptors so that WSS4JInterceptor is not used for UsernameToken
> processing at all. I'd appreciate if you could look into this refactoring
> yourself, there could be some subtleties there I'm not aware of. Also,
> personally I'd prefer registering a noop processor with WSS4J rather adding
> a flag to WSS4J, perhaps this noop processor can be used for handling other
> types of tokens, using an approach similar to the one taken by
> UsernameTokenInterceptor, unless yourself, David V, others have something
> else in mind...
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/WSS-229
> [2]
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
> pache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
> [3]
>
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
> g/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java<http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%0Ag/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java>
> [4]
>
> http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
> g/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml<http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or%0Ag/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml>
> [5] http://svn.apache.org/viewvc?rev=936521&view=rev
>
>
> On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin
> <sb...@gmail.com>wrote:
>
> > Hi
> >
> > I've added an initial patch for addressing a policy-first case, see [1].
> > It's a patch because it depends on another one I submitted to WSS4J [2].
> > Both patches need more work (tests, etc) but I'd just like to initiate a
> > discussion/review.
> >
> > The idea behind [1] is quite similar to the one used in supporting a
> > java-first case, where a custom interceptor extends an
> > AbstractWSS4JSecurityContextPr
> > oviding interceptor. But is is much simpler in [1] where
> > UsernameTokenProcessor may be optionally extended and its createSubject
> > method be overridden. Provided [2] gets applied then a subclass will just
> > have a property set disabling the (WSS4J) validation of passwords and
> will
> > do its own validation in createSubject method.
> >
> > This is really all what will be needed in simple cases, where a
> > DefaultSecurityContext will do, but optionally, createSecurityContext
> can
> > be overridden too.
> >
> > A user would need to set a bus property
> > "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a
> custom
> > interceptor which will indicate to the WSSecurityPolicyLoader that a
> custom
> > UsernameTokenProcessor subclass will need to be loaded.
> >
> > Similar approach can be employed for handling other types of tokens.
> >
> > cheers, Sergey
> >
> > [1] https://issues.apache.org/jira/browse/CXF-2754
> > [2] https://issues.apache.org/jira/browse/WSS-229
> >
> >
> > On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin
> <sb...@gmail.com>wrote:
> >
> >> Just realized I did not CC tp dev when replying to Dan the other day :
> >>
> >> Hi Dan
> >>
> >>
> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
> >>
> >>>
> >>> My main "concern" with the implementation of this is that it's done as
> a
> >>> direct subclass of the WSS4JInInterceptor and thus not really usable by
> >>> the
> >>> policy based endpoints as those interceptors subclass
> WSS4JInInterceptor
> >>> as
> >>> well.
> >>>
> >>> I think the better approach may be to add a flag to wss4j (I can help
> >>> commit
> >>> changes there if needed) to have it not do any UserName token
> processing
> >>> at
> >>> all. (aside: this may be doable without changes to wss4j by
> >>> registering our
> >>> own "do nothing processor") Then, have another interceptor that runs
> >>> after
> >>> the WSS4JInInterceptor that would actually handle the UsernameToken and
> >>> verify
> >>> anything it needs and such.
> >>>
> >>
> >> This sounds like a very good idea, I agree the proposed approach won't
> do
> >> for the cases where policies drive the
> >> creation of interceptors.
> >>
> >> Having said that, I think the abstract utility interceptor extending
> >> WSS4JInInterceptor
> >> may still be used in cases where users start from manually configuring
> >> jaxws endpoints. In these cases they'd need to
> >> list up to 3 interceptors (the one which extends
> >> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if
> the
> >> authorization is needed plus may be a SAAJ one) but otherwise, when say
> a
> >> clear text password has been encrypted, they'd still need to specify
> >> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
> >> UsernameTokenInterceptor, etc.
> >>
> >> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit
> complicated
> >> due to the fact it blocks the WSS4J digest checks and thus also creates
> a
> >> security engine per every request, but it all will be gone in due
> time...
> >>
> >>
> >>>
> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
> >>> There is
> >>> currently some duplicated code between the
> PolicyBasedWSS4JIinInterceptor
> >>> and
> >>> the new UsernameTokenInterceptor that could be eliminated by having the
> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
> delegate
> >>> that
> >>> completely to the UsernameTokenInterceptor.
> >>>
> >>
> >> What I will do is I will experiment with the test you added (thanks :-))
> >> and see how UsernameTokenInterceptor can be refactored
> >> so that a subclass can get an easy access to password, nonce, etc. I
> think
> >> I will need to come up with a contextual property so that a custom
> >> UsernameTokenInterceptor can be installed if needed. Or may be
> >> UsernameTokenInterceptor can store the details in a message to be later
> >> retrieved and processed for creating SecurityContext - but I'm not sure
> >> about it just yet.
> >>
> >>
> >>>
> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
> >>> encryption/signature stuff and then let the authorization validations
> >>> stuff to
> >>> later interceptors. That would include things like key validation
> >>> checking
> >>> and stuff as well. Probably SAML token validation as well.
> >>>
> >>>
> >> sounds good
> >>
> >> cheers, Sergey
> >>
> >> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
> >>
> >>>
> >>> My main "concern" with the implementation of this is that it's done as
> a
> >>> direct subclass of the WSS4JInInterceptor and thus not really usable by
> >>> the
> >>> policy based endpoints as those interceptors subclass
> WSS4JInInterceptor
> >>> as
> >>> well.
> >>>
> >>> I think the better approach may be to add a flag to wss4j (I can help
> >>> commit
> >>> changes there if needed) to have it not do any UserName token
> processing
> >>> at
> >>> all. (aside: this may be doable without changes to wss4j by
> >>> registering our
> >>> own "do nothing processor") Then, have another interceptor that runs
> >>> after
> >>> the WSS4JInInterceptor that would actually handle the UsernameToken and
> >>> verify
> >>> anything it needs and such.
> >>>
> >>> To be honest, I WANT to do this for the Policy based stuff anyway.
> >>> There is
> >>> currently some duplicated code between the
> PolicyBasedWSS4JIinInterceptor
> >>> and
> >>> the new UsernameTokenInterceptor that could be eliminated by having the
> >>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and
> delegate
> >>> that
> >>> completely to the UsernameTokenInterceptor.
> >>>
> >>> Basically, it would be good if the WSS4JIn* stuff just handled the
> >>> encryption/signature stuff and then let the authorization validations
> >>> stuff to
> >>> later interceptors. That would include things like key validation
> >>> checking
> >>> and stuff as well. Probably SAML token validation as well.
> >>>
> >>> Dan
> >>>
> >>>
> >>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
> >>> > Hi David
> >>> >
> >>> > thanks for the comments...
> >>> >
> >>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
> >>> wrote:
> >>> > > Sergey,
> >>> > >
> >>> > > I think this type of functionality would be very useful to a number
> >>> of
> >>> > > folks. I have built two similar capabilities for clients very
> >>> recently
> >>> > > using CXF and Spring Security. Based on the code provided below, I
> >>> have
> >>> > > several points that I would like to see addressed in a solution.
> >>> > >
> >>> > > 1) Architecture to support more than just UsernameTokens. I have
> >>> worked
> >>> > > with systems that need to authenticate a user using UsernameTokens,
> >>> > > BinarySecurityTokens, SAML Assertions, and a combination of more
> than
> >>> one
> >>> > > of
> >>> > > these at a time.
> >>> >
> >>> > Supporting UsernameTokens is the initial requirement. At the moment I
> >>> do
> >>> > not even know how BinarySecurityTokens or SAML Assertions are
> >>> > processed/validated in CXF or WSS4J.
> >>> >
> >>> > > For the most part, WSS4J simply validates the structural
> >>> > > details of security. That is, signature validity, trust chaining
> of
> >>> > > digital
> >>> > > certificates, etc. As Glen pointed out with his reference to
> >>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
> >>> performs
> >>> > > its
> >>> > > own password checking (authentication). Unfortunately, WSS4J
> doesn't
> >>> > > provide hooks for authenticating other forms of credentials that I
> >>> have
> >>> > > listed above (I don't consider trust to be equivalent to
> >>> authentication).
> >>> > > It would be best if the authentication interface supported multiple
> >>> > > credential types and allowed for authentication to be performed in
> a
> >>> > > single location in the same manner every time (not sometimes in the
> >>> > > WSS4J callback and sometimes in another interceptor for non-UT
> based
> >>> > > credentials).
> >>> >
> >>> > Makes sense. Assuming it is WSS4J which validates (the structure of)
> >>> > BinarySecurityTokens then
> >>> AbstractWSS4JSecurityContextProvidingInterceptor
> >>> > can also implement a processor for BinarySecurityTokens and delegate
> to
> >>> > subclass to authenticate and setup a subject. Some extra methods will
> >>> need
> >>> > to be added, to be optionally overridden.
> >>> >
> >>> > If it is not only WSS4J which is involved then perhaps another option
> >>> is to
> >>> > store (from WSS4J callback handler, etc) relevant details such
> username
> >>> > token details, etc to be acted upon by other interceptors.
> >>> >
> >>> > > That
> >>> > > last bit there means disabling WSS4J's password authentication
> since
> >>> it
> >>> > > gets
> >>> > > in the way of doing it later in our own interceptor.
> >>> >
> >>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
> >>> > implementing a simplified UsernameTokenProcessor
> >>> >
> >>> > > 2) Allow for end-user flexibility in choosing the credentials they
> >>> want
> >>> > > to authenticate. For instance, each user is going to have their
> own
> >>> > > security profiles and authentication requirements. For instance, a
> >>> > > message contains a UT for a portal user and a digital signature
> from
> >>> the
> >>> > > portal (I know using
> >>> > > a SAML Assertion would be better here, but people still do it this
> >>> way).
> >>> > > Each organization will have different requirements as to which
> >>> > > credentials get authenticated and what needs to end up in the
> >>> security
> >>> > > context.
> >>> >
> >>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
> >>> > should be able to do it, for username tokens and other tokens later
> on.
> >>> >
> >>> > > 3) Decouple the authentication interface from WSS4J. What is
> passed
> >>> in
> >>> > > needs to be abstracted enough that it can work with other
> WS-Security
> >>> > > libraries as well.
> >>> >
> >>> > the only WSS4J class which is leaked at the moment is
> >>> WSSecurityException.
> >>> > Perhaps we can come up later on with a different more generic
> approach
> >>> > which does not depend on WSS4J at all. As Dan indicated, in some
> cases
> >>> > WSS4JInInterceptor is not even used, so that case will need to be
> >>> > addressed. Experimenting wuth binary tokens might help with
> identifying
> >>> > another solution.
> >>> >
> >>> > > 4) It would be nice to be able to perform authorization using
> >>> something
> >>> > > like
> >>> > > Spring Security at the service operation level. With a POJO or
> >>> JAX-WS
> >>> > > based
> >>> > > service, one can just use Spring Security's method interceptor to
> >>> provide
> >>> > > such security; however, in situations where one only has a WSDL
> based
> >>> > > service or a provider style service, a method interceptor can't be
> >>> used.
> >>> > >
> >>> > > It
> >>> > >
> >>> > > would be nice to provide a hook into Spring Security to allow
> >>> end-users
> >>> > > to specify role based authorization policy based on a combination
> of
> >>> > > interface,
> >>> > > instance, and operation names. It seems like your
> >>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
> >>> > > looking in this direction, but I think it would be best if we can
> >>> stand
> >>> > > on the shoulders of the Spring Security giant as much as possible
> so
> >>> > > that we can take advantage of their rich authorization manager,
> >>> voter,
> >>> > > XML
> >>> > > configuration
> >>> > > capabilities.
> >>> >
> >>> > Not sure what to say here yet. But I think non-Spring users should be
> >>> taken
> >>> > care of too. Or when simpler cases are dealt with then perhaps
> there's
> >>> no
> >>> > need to bring in Spring security. Perhaps the utility authorization
> >>> > interceptors should just not be used when Spring Security is
> preferred
> >>> ?
> >>> >
> >>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
> >>> CXF-BC
> >>> > > currently has a limited capability to select the credentials to
> >>> > > authenticate
> >>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
> >>> delegates
> >>> > > authentication to the JBI container through a ServiceMix components
> >>> > > authentication service abstraction of JAAS. Whatever solution we
> >>> have
> >>> > > for 1
> >>> > > and 2 would help out the component if the ServiceMix authentication
> >>> > > service abstraction could be wired up in lieu of whatever we
> provide
> >>> out
> >>> > > of the box.
> >>> >
> >>> > I'm not planning to contribute to ServiceMix. I agree though that an
> >>> ideal
> >>> > solution will meet multiple requirements
> >>> >
> >>> > thanks, Sergey
> >>> >
> >>> > > -----Original Message-----
> >>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> >>> > > Sent: Wednesday, April 07, 2010 10:11 AM
> >>> > > To: dev@cxf.apache.org
> >>> > > Subject: Using WS-Security UsernameToken to authenticate users and
> >>> > > populate SecurityContexts
> >>> > >
> >>> > > Hi
> >>> > >
> >>> > > I've been looking recently at extending the CXF WS-Security
> component
> >>> > > such that a current UsernameToken could be used by custom
> >>> interceptors
> >>> > > to authenticate a user with the external security systems and, if
> >>> > > possible, provide enough information for CXF to populate a
> >>> > > SecurityContext [1] to be used later on for
> >>> > > authorization decisions.
> >>> > >
> >>> > > Here is the approach I've taken so far.
> >>> > > A custom interceptor extends
> >>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
> >>> method
> >>> > > it overrides is
> >>> > >
> >>> > > abstract Subject createSubject(String name, String password,
> boolean
> >>> > > isDigest,
> >>> > >
> >>> > > String nonce,
> >>> > > String created) throws
> >>> > >
> >>> > > WSSecurityException;
> >>> > >
> >>> > >
> >>> > > For example, see [3].
> >>> > >
> >>> > > The idea here is that a custom interceptor interfaces whichever way
> >>> it
> >>> > > needs
> >>> > > to with the external system and populates a Subject following this
> >>> simple
> >>> > > rule : first Subject principal is the current user (identified by a
> >>> > > 'name' argument), followed by one or more Groups this user is a
> >>> member
> >>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
> >>> > > Subject to provide a functional SecurityContext instance.
> >>> > >
> >>> > > This is the first part, next is how to utilize a SecurityContext
> and
> >>> get
> >>> > > the
> >>> > > expected roles associated one way or the other with a current
> method
> >>> to
> >>> > > be invoked. There's a number of usual options available here,
> perhaps
> >>> > > even SpringSecurity can be used now that SecurityContext is
> >>> available,
> >>> > > or application code or other custom CXF interceptor can check the
> >>> known
> >>> > > roles against SecurityContext.
> >>> > >
> >>> > > I've also added AbstractAuthorizingInInterceptor interceptor which
> >>> custom
> >>> > > interceptors can override and return a list of expected roles given
> a
> >>> > > (service) Method to be invoked upon,
> AbstractAuthorizingInInterceptor
> >>> > > will then ask available SecurityContext to match the roles; one
> >>> concrete
> >>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
> injected
> >>> > > with a
> >>> > > method specific or class (applying to all methods) roles. Another
> >>> > > implementation which I will likely add later on will be injected
> with
> >>> a
> >>> > > name
> >>> > > of annotation such as RolesAlloved and it will introspect a method
> >>> and
> >>> > > its class.
> >>> > >
> >>> > > Note that I haven't looked into the case when a policy runtimes
> adds
> >>> the
> >>> > > interceptors yet (as opposed to interceptors being configured form
> >>> > > Spring/programmatically). I think an optional contextual property
> >>> will
> >>> > > need to be setup in such cases for users be able to indicate that
> say
> >>> an
> >>> > > interceptor such as [3] has to be used as opposed to
> >>> WSS4JInInterceptor,
> >>> > > etc.
> >>> > >
> >>> > > I'm going to validate this approach with JBoss CXF. If you have any
> >>> > > comments
> >>> > > then please let me know.
> >>> > >
> >>> > > I think we may have a simpler alternative eventually to the way
> >>> > > authorization decisions are made. [1]-[3] is specific to
> ws-security,
> >>> but
> >>> > > [4]-[5] is not
> >>> > >
> >>> > > cheers, Sergey
> >>> > >
> >>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
> >>> > > [2]
> >>> > >
> >>> > >
> >>>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
> >>> > > g/a
> >>> > >
> >>> > >
> >>>
> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
> >>> > > tor<
> >>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
> >>> > >
> >>>
> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
> >>> > > ngInterceptor> .java
> >>> > > [3]
> >>> > >
> >>> > >
> >>>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
> >>> > > g/a
> >>> > >
> >>>
> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
> >>> > > /
> >>>
> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
> >>> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
> >>> [4]
> >>> > >
> >>> > >
> >>>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> >>> > > e/c
> >>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
> >>> http://svn
> >>> > > .
> >>>
> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
> >>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
> >>> > >
> >>> > >
> >>>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> >>> > > e/c
> >>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
> >>> http://svn.apa
> >>> > >
> >>>
> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
> >>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
> >>>
> >>> --
> >>> Daniel Kulp
> >>> dkulp@apache.org
> >>> http://dankulp.com/blog
> >>>
> >>
> >>
> >
>
RE: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Posted by David Valeri <dv...@apache.org>.
Attached are some quick and dirty class/seq diagrams that outline a slightly
different approach to determining which credentials to authenticate,
choosing how to extract them, and then actually performing the
authentication.
This approach would still require configuring your customized UT Processor
in WSS4J in order to disable WSS4Js clumsy authentication system but moves
the work of creating the SecurityContext and JAAS subject out of the WSS4J
interceptors and into generic authentication framework. It looks like
WSS4JInInterceptor simply looks for the first principal it finds in the
WSS4J results and sends that on its way. When multiple tokens appear in a
message, this approach may not always grab the one the application really
requires.
This approach works after the WSS4J security processing completes and
examines the results from WSS4J, or another security framework if we ever
use one, and determines which profile is in effect. A delegate interceptor
is then called to extract the correct user credentials from the message and
perform any additional validation that is needed for a given profile. The
extracted credentials are then passed to an AuthenticationStrategy to
perform the actual authentication. The AuthenticationService would return
something like a JAAS Subject that is then used to create the CXF
SecurityContext. As you can see, the "Credentials" concept is pretty vague
as there are many different types of credentials out there. I feel that the
most common two are X509 certificates and Username Tokens.
This approach requires many more classes and could be more complex to
configure. I have not thoroughly been over what the default SecurityProfile
evaluator should be like nor do I know what concrete implementations of
AbstractSecurityContextProvidingInterceptor should be provided. What I feel
to be the three most common interceptor instances are listed in the class
diagram. As for the default SecurityProfileChooser, I initially suggest
that it simply allows the user to enable/disable no security, TLS, BST, and
UT while allowing the end user to configure the desired precedence of each
profile over the other.
This approach can easily work with Spring Security as an
AuthenticationService implementation.
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Wednesday, April 21, 2010 5:47 PM
To: Daniel Kulp
Cc: dev@cxf.apache.org
Subject: Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
I added a system test for a policy first case and refactored few bits along
the way, as well as closed [1] as 'Wont fix', at least for now.
I've just updated UsernameTokenInterceptor[1] so that a (WSS4J) principal
can be created directly if a message property disabling the validation of
passwords has been set.
This property can be set as a jaxws contextual property in which case
interceptors further in the chain will be able to get the (unauthenticated)
Principal, validate it, and set a SecurityContext as needed.
Another approach used in the system test is to write a custom interceptor[3]
extending UsernameTokenInterceptor and disable the validation from there.
This custom interceptor is currently being registered by setting a bus
property, see [4]. Note that a jaxws endpoint adds
SimpleAuthorizationInterceptor only and has no callbacks registered.
See [5] for more details.
It looks quite reasonable to me at the moment, perhaps there could be a
simpler way to register custom interceptors.
Dan, you've mentioned the fact you were planning to refactor some of the
policy interceptors so that WSS4JInterceptor is not used for UsernameToken
processing at all. I'd appreciate if you could look into this refactoring
yourself, there could be some subtleties there I'm not aware of. Also,
personally I'd prefer registering a noop processor with WSS4J rather adding
a flag to WSS4J, perhaps this noop processor can be used for handling other
types of tokens, using an approach similar to the one taken by
UsernameTokenInterceptor, unless yourself, David V, others have something
else in mind...
cheers, Sergey
[1] https://issues.apache.org/jira/browse/WSS-229
[2]
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
pache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
[3]
http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
g/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java
[4]
http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/or
g/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml
[5] http://svn.apache.org/viewvc?rev=936521&view=rev
On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin
<sb...@gmail.com>wrote:
> Hi
>
> I've added an initial patch for addressing a policy-first case, see [1].
> It's a patch because it depends on another one I submitted to WSS4J [2].
> Both patches need more work (tests, etc) but I'd just like to initiate a
> discussion/review.
>
> The idea behind [1] is quite similar to the one used in supporting a
> java-first case, where a custom interceptor extends an
> AbstractWSS4JSecurityContextPr
> oviding interceptor. But is is much simpler in [1] where
> UsernameTokenProcessor may be optionally extended and its createSubject
> method be overridden. Provided [2] gets applied then a subclass will just
> have a property set disabling the (WSS4J) validation of passwords and will
> do its own validation in createSubject method.
>
> This is really all what will be needed in simple cases, where a
> DefaultSecurityContext will do, but optionally, createSecurityContext can
> be overridden too.
>
> A user would need to set a bus property
> "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a
custom
> interceptor which will indicate to the WSSecurityPolicyLoader that a
custom
> UsernameTokenProcessor subclass will need to be loaded.
>
> Similar approach can be employed for handling other types of tokens.
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/CXF-2754
> [2] https://issues.apache.org/jira/browse/WSS-229
>
>
> On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin
<sb...@gmail.com>wrote:
>
>> Just realized I did not CC tp dev when replying to Dan the other day :
>>
>> Hi Dan
>>
>>
>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> My main "concern" with the implementation of this is that it's done as a
>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>> the
>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>> as
>>> well.
>>>
>>> I think the better approach may be to add a flag to wss4j (I can help
>>> commit
>>> changes there if needed) to have it not do any UserName token processing
>>> at
>>> all. (aside: this may be doable without changes to wss4j by
>>> registering our
>>> own "do nothing processor") Then, have another interceptor that runs
>>> after
>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>> verify
>>> anything it needs and such.
>>>
>>
>> This sounds like a very good idea, I agree the proposed approach won't do
>> for the cases where policies drive the
>> creation of interceptors.
>>
>> Having said that, I think the abstract utility interceptor extending
>> WSS4JInInterceptor
>> may still be used in cases where users start from manually configuring
>> jaxws endpoints. In these cases they'd need to
>> list up to 3 interceptors (the one which extends
>> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if
the
>> authorization is needed plus may be a SAAJ one) but otherwise, when say a
>> clear text password has been encrypted, they'd still need to specify
>> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
>> UsernameTokenInterceptor, etc.
>>
>> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit complicated
>> due to the fact it blocks the WSS4J digest checks and thus also creates a
>> security engine per every request, but it all will be gone in due time...
>>
>>
>>>
>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>> There is
>>> currently some duplicated code between the
PolicyBasedWSS4JIinInterceptor
>>> and
>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>> that
>>> completely to the UsernameTokenInterceptor.
>>>
>>
>> What I will do is I will experiment with the test you added (thanks :-))
>> and see how UsernameTokenInterceptor can be refactored
>> so that a subclass can get an easy access to password, nonce, etc. I
think
>> I will need to come up with a contextual property so that a custom
>> UsernameTokenInterceptor can be installed if needed. Or may be
>> UsernameTokenInterceptor can store the details in a message to be later
>> retrieved and processed for creating SecurityContext - but I'm not sure
>> about it just yet.
>>
>>
>>>
>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>> encryption/signature stuff and then let the authorization validations
>>> stuff to
>>> later interceptors. That would include things like key validation
>>> checking
>>> and stuff as well. Probably SAML token validation as well.
>>>
>>>
>> sounds good
>>
>> cheers, Sergey
>>
>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> My main "concern" with the implementation of this is that it's done as a
>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>> the
>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>> as
>>> well.
>>>
>>> I think the better approach may be to add a flag to wss4j (I can help
>>> commit
>>> changes there if needed) to have it not do any UserName token processing
>>> at
>>> all. (aside: this may be doable without changes to wss4j by
>>> registering our
>>> own "do nothing processor") Then, have another interceptor that runs
>>> after
>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>> verify
>>> anything it needs and such.
>>>
>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>> There is
>>> currently some duplicated code between the
PolicyBasedWSS4JIinInterceptor
>>> and
>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>> that
>>> completely to the UsernameTokenInterceptor.
>>>
>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>> encryption/signature stuff and then let the authorization validations
>>> stuff to
>>> later interceptors. That would include things like key validation
>>> checking
>>> and stuff as well. Probably SAML token validation as well.
>>>
>>> Dan
>>>
>>>
>>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
>>> > Hi David
>>> >
>>> > thanks for the comments...
>>> >
>>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
>>> wrote:
>>> > > Sergey,
>>> > >
>>> > > I think this type of functionality would be very useful to a number
>>> of
>>> > > folks. I have built two similar capabilities for clients very
>>> recently
>>> > > using CXF and Spring Security. Based on the code provided below, I
>>> have
>>> > > several points that I would like to see addressed in a solution.
>>> > >
>>> > > 1) Architecture to support more than just UsernameTokens. I have
>>> worked
>>> > > with systems that need to authenticate a user using UsernameTokens,
>>> > > BinarySecurityTokens, SAML Assertions, and a combination of more
than
>>> one
>>> > > of
>>> > > these at a time.
>>> >
>>> > Supporting UsernameTokens is the initial requirement. At the moment I
>>> do
>>> > not even know how BinarySecurityTokens or SAML Assertions are
>>> > processed/validated in CXF or WSS4J.
>>> >
>>> > > For the most part, WSS4J simply validates the structural
>>> > > details of security. That is, signature validity, trust chaining of
>>> > > digital
>>> > > certificates, etc. As Glen pointed out with his reference to
>>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
>>> performs
>>> > > its
>>> > > own password checking (authentication). Unfortunately, WSS4J
doesn't
>>> > > provide hooks for authenticating other forms of credentials that I
>>> have
>>> > > listed above (I don't consider trust to be equivalent to
>>> authentication).
>>> > > It would be best if the authentication interface supported multiple
>>> > > credential types and allowed for authentication to be performed in a
>>> > > single location in the same manner every time (not sometimes in the
>>> > > WSS4J callback and sometimes in another interceptor for non-UT based
>>> > > credentials).
>>> >
>>> > Makes sense. Assuming it is WSS4J which validates (the structure of)
>>> > BinarySecurityTokens then
>>> AbstractWSS4JSecurityContextProvidingInterceptor
>>> > can also implement a processor for BinarySecurityTokens and delegate
to
>>> > subclass to authenticate and setup a subject. Some extra methods will
>>> need
>>> > to be added, to be optionally overridden.
>>> >
>>> > If it is not only WSS4J which is involved then perhaps another option
>>> is to
>>> > store (from WSS4J callback handler, etc) relevant details such
username
>>> > token details, etc to be acted upon by other interceptors.
>>> >
>>> > > That
>>> > > last bit there means disabling WSS4J's password authentication since
>>> it
>>> > > gets
>>> > > in the way of doing it later in our own interceptor.
>>> >
>>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
>>> > implementing a simplified UsernameTokenProcessor
>>> >
>>> > > 2) Allow for end-user flexibility in choosing the credentials they
>>> want
>>> > > to authenticate. For instance, each user is going to have their own
>>> > > security profiles and authentication requirements. For instance, a
>>> > > message contains a UT for a portal user and a digital signature from
>>> the
>>> > > portal (I know using
>>> > > a SAML Assertion would be better here, but people still do it this
>>> way).
>>> > > Each organization will have different requirements as to which
>>> > > credentials get authenticated and what needs to end up in the
>>> security
>>> > > context.
>>> >
>>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
>>> > should be able to do it, for username tokens and other tokens later
on.
>>> >
>>> > > 3) Decouple the authentication interface from WSS4J. What is passed
>>> in
>>> > > needs to be abstracted enough that it can work with other
WS-Security
>>> > > libraries as well.
>>> >
>>> > the only WSS4J class which is leaked at the moment is
>>> WSSecurityException.
>>> > Perhaps we can come up later on with a different more generic approach
>>> > which does not depend on WSS4J at all. As Dan indicated, in some cases
>>> > WSS4JInInterceptor is not even used, so that case will need to be
>>> > addressed. Experimenting wuth binary tokens might help with
identifying
>>> > another solution.
>>> >
>>> > > 4) It would be nice to be able to perform authorization using
>>> something
>>> > > like
>>> > > Spring Security at the service operation level. With a POJO or
>>> JAX-WS
>>> > > based
>>> > > service, one can just use Spring Security's method interceptor to
>>> provide
>>> > > such security; however, in situations where one only has a WSDL
based
>>> > > service or a provider style service, a method interceptor can't be
>>> used.
>>> > >
>>> > > It
>>> > >
>>> > > would be nice to provide a hook into Spring Security to allow
>>> end-users
>>> > > to specify role based authorization policy based on a combination of
>>> > > interface,
>>> > > instance, and operation names. It seems like your
>>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
>>> > > looking in this direction, but I think it would be best if we can
>>> stand
>>> > > on the shoulders of the Spring Security giant as much as possible so
>>> > > that we can take advantage of their rich authorization manager,
>>> voter,
>>> > > XML
>>> > > configuration
>>> > > capabilities.
>>> >
>>> > Not sure what to say here yet. But I think non-Spring users should be
>>> taken
>>> > care of too. Or when simpler cases are dealt with then perhaps there's
>>> no
>>> > need to bring in Spring security. Perhaps the utility authorization
>>> > interceptors should just not be used when Spring Security is preferred
>>> ?
>>> >
>>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
>>> CXF-BC
>>> > > currently has a limited capability to select the credentials to
>>> > > authenticate
>>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
>>> delegates
>>> > > authentication to the JBI container through a ServiceMix components
>>> > > authentication service abstraction of JAAS. Whatever solution we
>>> have
>>> > > for 1
>>> > > and 2 would help out the component if the ServiceMix authentication
>>> > > service abstraction could be wired up in lieu of whatever we provide
>>> out
>>> > > of the box.
>>> >
>>> > I'm not planning to contribute to ServiceMix. I agree though that an
>>> ideal
>>> > solution will meet multiple requirements
>>> >
>>> > thanks, Sergey
>>> >
>>> > > -----Original Message-----
>>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>>> > > Sent: Wednesday, April 07, 2010 10:11 AM
>>> > > To: dev@cxf.apache.org
>>> > > Subject: Using WS-Security UsernameToken to authenticate users and
>>> > > populate SecurityContexts
>>> > >
>>> > > Hi
>>> > >
>>> > > I've been looking recently at extending the CXF WS-Security
component
>>> > > such that a current UsernameToken could be used by custom
>>> interceptors
>>> > > to authenticate a user with the external security systems and, if
>>> > > possible, provide enough information for CXF to populate a
>>> > > SecurityContext [1] to be used later on for
>>> > > authorization decisions.
>>> > >
>>> > > Here is the approach I've taken so far.
>>> > > A custom interceptor extends
>>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
>>> method
>>> > > it overrides is
>>> > >
>>> > > abstract Subject createSubject(String name, String password, boolean
>>> > > isDigest,
>>> > >
>>> > > String nonce,
>>> > > String created) throws
>>> > >
>>> > > WSSecurityException;
>>> > >
>>> > >
>>> > > For example, see [3].
>>> > >
>>> > > The idea here is that a custom interceptor interfaces whichever way
>>> it
>>> > > needs
>>> > > to with the external system and populates a Subject following this
>>> simple
>>> > > rule : first Subject principal is the current user (identified by a
>>> > > 'name' argument), followed by one or more Groups this user is a
>>> member
>>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
>>> > > Subject to provide a functional SecurityContext instance.
>>> > >
>>> > > This is the first part, next is how to utilize a SecurityContext and
>>> get
>>> > > the
>>> > > expected roles associated one way or the other with a current method
>>> to
>>> > > be invoked. There's a number of usual options available here,
perhaps
>>> > > even SpringSecurity can be used now that SecurityContext is
>>> available,
>>> > > or application code or other custom CXF interceptor can check the
>>> known
>>> > > roles against SecurityContext.
>>> > >
>>> > > I've also added AbstractAuthorizingInInterceptor interceptor which
>>> custom
>>> > > interceptors can override and return a list of expected roles given
a
>>> > > (service) Method to be invoked upon,
AbstractAuthorizingInInterceptor
>>> > > will then ask available SecurityContext to match the roles; one
>>> concrete
>>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
injected
>>> > > with a
>>> > > method specific or class (applying to all methods) roles. Another
>>> > > implementation which I will likely add later on will be injected
with
>>> a
>>> > > name
>>> > > of annotation such as RolesAlloved and it will introspect a method
>>> and
>>> > > its class.
>>> > >
>>> > > Note that I haven't looked into the case when a policy runtimes adds
>>> the
>>> > > interceptors yet (as opposed to interceptors being configured form
>>> > > Spring/programmatically). I think an optional contextual property
>>> will
>>> > > need to be setup in such cases for users be able to indicate that
say
>>> an
>>> > > interceptor such as [3] has to be used as opposed to
>>> WSS4JInInterceptor,
>>> > > etc.
>>> > >
>>> > > I'm going to validate this approach with JBoss CXF. If you have any
>>> > > comments
>>> > > then please let me know.
>>> > >
>>> > > I think we may have a simpler alternative eventually to the way
>>> > > authorization decisions are made. [1]-[3] is specific to
ws-security,
>>> but
>>> > > [4]-[5] is not
>>> > >
>>> > > cheers, Sergey
>>> > >
>>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
>>> > > [2]
>>> > >
>>> > >
>>>
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
>>> > > g/a
>>> > >
>>> > >
>>>
pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
>>> > > tor<
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
>>> > >
>>>
a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
>>> > > ngInterceptor> .java
>>> > > [3]
>>> > >
>>> > >
>>>
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
>>> > > g/a
>>> > >
>>> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
>>> > > /
>>> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
>>> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
>>> [4]
>>> > >
>>> > >
>>>
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>> > > e/c
>>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
>>> http://svn
>>> > > .
>>> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
>>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
>>> > >
>>> > >
>>>
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>> > > e/c
>>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
>>> http://svn.apa
>>> > >
>>>
che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
>>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>>
>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
I added a system test for a policy first case and refactored few bits along
the way, as well as closed [1] as 'Wont fix', at least for now.
I've just updated UsernameTokenInterceptor[1] so that a (WSS4J) principal
can be created directly if a message property disabling the validation of
passwords has been set.
This property can be set as a jaxws contextual property in which case
interceptors further in the chain will be able to get the (unauthenticated)
Principal, validate it, and set a SecurityContext as needed.
Another approach used in the system test is to write a custom interceptor[3]
extending UsernameTokenInterceptor and disable the validation from there.
This custom interceptor is currently being registered by setting a bus
property, see [4]. Note that a jaxws endpoint adds
SimpleAuthorizationInterceptor only and has no callbacks registered.
See [5] for more details.
It looks quite reasonable to me at the moment, perhaps there could be a
simpler way to register custom interceptors.
Dan, you've mentioned the fact you were planning to refactor some of the
policy interceptors so that WSS4JInterceptor is not used for UsernameToken
processing at all. I'd appreciate if you could look into this refactoring
yourself, there could be some subtleties there I'm not aware of. Also,
personally I'd prefer registering a noop processor with WSS4J rather adding
a flag to WSS4J, perhaps this noop processor can be used for handling other
types of tokens, using an approach similar to the one taken by
UsernameTokenInterceptor, unless yourself, David V, others have something
else in mind...
cheers, Sergey
[1] https://issues.apache.org/jira/browse/WSS-229
[2]
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java
[3]
http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/CustomUsernameTokenInterceptor.java
[4]
http://svn.apache.org/repos/asf/cxf/trunk/systests/ws-specs/src/test/java/org/apache/cxf/systest/ws/wssec10/server/server_restricted_authorized.xml
[5] http://svn.apache.org/viewvc?rev=936521&view=rev
On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi
>
> I've added an initial patch for addressing a policy-first case, see [1].
> It's a patch because it depends on another one I submitted to WSS4J [2].
> Both patches need more work (tests, etc) but I'd just like to initiate a
> discussion/review.
>
> The idea behind [1] is quite similar to the one used in supporting a
> java-first case, where a custom interceptor extends an
> AbstractWSS4JSecurityContextPr
> oviding interceptor. But is is much simpler in [1] where
> UsernameTokenProcessor may be optionally extended and its createSubject
> method be overridden. Provided [2] gets applied then a subclass will just
> have a property set disabling the (WSS4J) validation of passwords and will
> do its own validation in createSubject method.
>
> This is really all what will be needed in simple cases, where a
> DefaultSecurityContext will do, but optionally, createSecurityContext can
> be overridden too.
>
> A user would need to set a bus property
> "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a custom
> interceptor which will indicate to the WSSecurityPolicyLoader that a custom
> UsernameTokenProcessor subclass will need to be loaded.
>
> Similar approach can be employed for handling other types of tokens.
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/CXF-2754
> [2] https://issues.apache.org/jira/browse/WSS-229
>
>
> On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
>
>> Just realized I did not CC tp dev when replying to Dan the other day :
>>
>> Hi Dan
>>
>>
>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> My main "concern" with the implementation of this is that it's done as a
>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>> the
>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>> as
>>> well.
>>>
>>> I think the better approach may be to add a flag to wss4j (I can help
>>> commit
>>> changes there if needed) to have it not do any UserName token processing
>>> at
>>> all. (aside: this may be doable without changes to wss4j by
>>> registering our
>>> own "do nothing processor") Then, have another interceptor that runs
>>> after
>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>> verify
>>> anything it needs and such.
>>>
>>
>> This sounds like a very good idea, I agree the proposed approach won't do
>> for the cases where policies drive the
>> creation of interceptors.
>>
>> Having said that, I think the abstract utility interceptor extending
>> WSS4JInInterceptor
>> may still be used in cases where users start from manually configuring
>> jaxws endpoints. In these cases they'd need to
>> list up to 3 interceptors (the one which extends
>> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if the
>> authorization is needed plus may be a SAAJ one) but otherwise, when say a
>> clear text password has been encrypted, they'd still need to specify
>> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
>> UsernameTokenInterceptor, etc.
>>
>> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit complicated
>> due to the fact it blocks the WSS4J digest checks and thus also creates a
>> security engine per every request, but it all will be gone in due time...
>>
>>
>>>
>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>> There is
>>> currently some duplicated code between the PolicyBasedWSS4JIinInterceptor
>>> and
>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>> that
>>> completely to the UsernameTokenInterceptor.
>>>
>>
>> What I will do is I will experiment with the test you added (thanks :-))
>> and see how UsernameTokenInterceptor can be refactored
>> so that a subclass can get an easy access to password, nonce, etc. I think
>> I will need to come up with a contextual property so that a custom
>> UsernameTokenInterceptor can be installed if needed. Or may be
>> UsernameTokenInterceptor can store the details in a message to be later
>> retrieved and processed for creating SecurityContext - but I'm not sure
>> about it just yet.
>>
>>
>>>
>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>> encryption/signature stuff and then let the authorization validations
>>> stuff to
>>> later interceptors. That would include things like key validation
>>> checking
>>> and stuff as well. Probably SAML token validation as well.
>>>
>>>
>> sounds good
>>
>> cheers, Sergey
>>
>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> My main "concern" with the implementation of this is that it's done as a
>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>> the
>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>> as
>>> well.
>>>
>>> I think the better approach may be to add a flag to wss4j (I can help
>>> commit
>>> changes there if needed) to have it not do any UserName token processing
>>> at
>>> all. (aside: this may be doable without changes to wss4j by
>>> registering our
>>> own "do nothing processor") Then, have another interceptor that runs
>>> after
>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>> verify
>>> anything it needs and such.
>>>
>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>> There is
>>> currently some duplicated code between the PolicyBasedWSS4JIinInterceptor
>>> and
>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>> that
>>> completely to the UsernameTokenInterceptor.
>>>
>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>> encryption/signature stuff and then let the authorization validations
>>> stuff to
>>> later interceptors. That would include things like key validation
>>> checking
>>> and stuff as well. Probably SAML token validation as well.
>>>
>>> Dan
>>>
>>>
>>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
>>> > Hi David
>>> >
>>> > thanks for the comments...
>>> >
>>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
>>> wrote:
>>> > > Sergey,
>>> > >
>>> > > I think this type of functionality would be very useful to a number
>>> of
>>> > > folks. I have built two similar capabilities for clients very
>>> recently
>>> > > using CXF and Spring Security. Based on the code provided below, I
>>> have
>>> > > several points that I would like to see addressed in a solution.
>>> > >
>>> > > 1) Architecture to support more than just UsernameTokens. I have
>>> worked
>>> > > with systems that need to authenticate a user using UsernameTokens,
>>> > > BinarySecurityTokens, SAML Assertions, and a combination of more than
>>> one
>>> > > of
>>> > > these at a time.
>>> >
>>> > Supporting UsernameTokens is the initial requirement. At the moment I
>>> do
>>> > not even know how BinarySecurityTokens or SAML Assertions are
>>> > processed/validated in CXF or WSS4J.
>>> >
>>> > > For the most part, WSS4J simply validates the structural
>>> > > details of security. That is, signature validity, trust chaining of
>>> > > digital
>>> > > certificates, etc. As Glen pointed out with his reference to
>>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
>>> performs
>>> > > its
>>> > > own password checking (authentication). Unfortunately, WSS4J doesn't
>>> > > provide hooks for authenticating other forms of credentials that I
>>> have
>>> > > listed above (I don't consider trust to be equivalent to
>>> authentication).
>>> > > It would be best if the authentication interface supported multiple
>>> > > credential types and allowed for authentication to be performed in a
>>> > > single location in the same manner every time (not sometimes in the
>>> > > WSS4J callback and sometimes in another interceptor for non-UT based
>>> > > credentials).
>>> >
>>> > Makes sense. Assuming it is WSS4J which validates (the structure of)
>>> > BinarySecurityTokens then
>>> AbstractWSS4JSecurityContextProvidingInterceptor
>>> > can also implement a processor for BinarySecurityTokens and delegate to
>>> > subclass to authenticate and setup a subject. Some extra methods will
>>> need
>>> > to be added, to be optionally overridden.
>>> >
>>> > If it is not only WSS4J which is involved then perhaps another option
>>> is to
>>> > store (from WSS4J callback handler, etc) relevant details such username
>>> > token details, etc to be acted upon by other interceptors.
>>> >
>>> > > That
>>> > > last bit there means disabling WSS4J's password authentication since
>>> it
>>> > > gets
>>> > > in the way of doing it later in our own interceptor.
>>> >
>>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
>>> > implementing a simplified UsernameTokenProcessor
>>> >
>>> > > 2) Allow for end-user flexibility in choosing the credentials they
>>> want
>>> > > to authenticate. For instance, each user is going to have their own
>>> > > security profiles and authentication requirements. For instance, a
>>> > > message contains a UT for a portal user and a digital signature from
>>> the
>>> > > portal (I know using
>>> > > a SAML Assertion would be better here, but people still do it this
>>> way).
>>> > > Each organization will have different requirements as to which
>>> > > credentials get authenticated and what needs to end up in the
>>> security
>>> > > context.
>>> >
>>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
>>> > should be able to do it, for username tokens and other tokens later on.
>>> >
>>> > > 3) Decouple the authentication interface from WSS4J. What is passed
>>> in
>>> > > needs to be abstracted enough that it can work with other WS-Security
>>> > > libraries as well.
>>> >
>>> > the only WSS4J class which is leaked at the moment is
>>> WSSecurityException.
>>> > Perhaps we can come up later on with a different more generic approach
>>> > which does not depend on WSS4J at all. As Dan indicated, in some cases
>>> > WSS4JInInterceptor is not even used, so that case will need to be
>>> > addressed. Experimenting wuth binary tokens might help with identifying
>>> > another solution.
>>> >
>>> > > 4) It would be nice to be able to perform authorization using
>>> something
>>> > > like
>>> > > Spring Security at the service operation level. With a POJO or
>>> JAX-WS
>>> > > based
>>> > > service, one can just use Spring Security's method interceptor to
>>> provide
>>> > > such security; however, in situations where one only has a WSDL based
>>> > > service or a provider style service, a method interceptor can't be
>>> used.
>>> > >
>>> > > It
>>> > >
>>> > > would be nice to provide a hook into Spring Security to allow
>>> end-users
>>> > > to specify role based authorization policy based on a combination of
>>> > > interface,
>>> > > instance, and operation names. It seems like your
>>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
>>> > > looking in this direction, but I think it would be best if we can
>>> stand
>>> > > on the shoulders of the Spring Security giant as much as possible so
>>> > > that we can take advantage of their rich authorization manager,
>>> voter,
>>> > > XML
>>> > > configuration
>>> > > capabilities.
>>> >
>>> > Not sure what to say here yet. But I think non-Spring users should be
>>> taken
>>> > care of too. Or when simpler cases are dealt with then perhaps there's
>>> no
>>> > need to bring in Spring security. Perhaps the utility authorization
>>> > interceptors should just not be used when Spring Security is preferred
>>> ?
>>> >
>>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
>>> CXF-BC
>>> > > currently has a limited capability to select the credentials to
>>> > > authenticate
>>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
>>> delegates
>>> > > authentication to the JBI container through a ServiceMix components
>>> > > authentication service abstraction of JAAS. Whatever solution we
>>> have
>>> > > for 1
>>> > > and 2 would help out the component if the ServiceMix authentication
>>> > > service abstraction could be wired up in lieu of whatever we provide
>>> out
>>> > > of the box.
>>> >
>>> > I'm not planning to contribute to ServiceMix. I agree though that an
>>> ideal
>>> > solution will meet multiple requirements
>>> >
>>> > thanks, Sergey
>>> >
>>> > > -----Original Message-----
>>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>>> > > Sent: Wednesday, April 07, 2010 10:11 AM
>>> > > To: dev@cxf.apache.org
>>> > > Subject: Using WS-Security UsernameToken to authenticate users and
>>> > > populate SecurityContexts
>>> > >
>>> > > Hi
>>> > >
>>> > > I've been looking recently at extending the CXF WS-Security component
>>> > > such that a current UsernameToken could be used by custom
>>> interceptors
>>> > > to authenticate a user with the external security systems and, if
>>> > > possible, provide enough information for CXF to populate a
>>> > > SecurityContext [1] to be used later on for
>>> > > authorization decisions.
>>> > >
>>> > > Here is the approach I've taken so far.
>>> > > A custom interceptor extends
>>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
>>> method
>>> > > it overrides is
>>> > >
>>> > > abstract Subject createSubject(String name, String password, boolean
>>> > > isDigest,
>>> > >
>>> > > String nonce,
>>> > > String created) throws
>>> > >
>>> > > WSSecurityException;
>>> > >
>>> > >
>>> > > For example, see [3].
>>> > >
>>> > > The idea here is that a custom interceptor interfaces whichever way
>>> it
>>> > > needs
>>> > > to with the external system and populates a Subject following this
>>> simple
>>> > > rule : first Subject principal is the current user (identified by a
>>> > > 'name' argument), followed by one or more Groups this user is a
>>> member
>>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
>>> > > Subject to provide a functional SecurityContext instance.
>>> > >
>>> > > This is the first part, next is how to utilize a SecurityContext and
>>> get
>>> > > the
>>> > > expected roles associated one way or the other with a current method
>>> to
>>> > > be invoked. There's a number of usual options available here, perhaps
>>> > > even SpringSecurity can be used now that SecurityContext is
>>> available,
>>> > > or application code or other custom CXF interceptor can check the
>>> known
>>> > > roles against SecurityContext.
>>> > >
>>> > > I've also added AbstractAuthorizingInInterceptor interceptor which
>>> custom
>>> > > interceptors can override and return a list of expected roles given a
>>> > > (service) Method to be invoked upon, AbstractAuthorizingInInterceptor
>>> > > will then ask available SecurityContext to match the roles; one
>>> concrete
>>> > > implementation is SimpleAuthorizingInterceptor[5], it can be injected
>>> > > with a
>>> > > method specific or class (applying to all methods) roles. Another
>>> > > implementation which I will likely add later on will be injected with
>>> a
>>> > > name
>>> > > of annotation such as RolesAlloved and it will introspect a method
>>> and
>>> > > its class.
>>> > >
>>> > > Note that I haven't looked into the case when a policy runtimes adds
>>> the
>>> > > interceptors yet (as opposed to interceptors being configured form
>>> > > Spring/programmatically). I think an optional contextual property
>>> will
>>> > > need to be setup in such cases for users be able to indicate that say
>>> an
>>> > > interceptor such as [3] has to be used as opposed to
>>> WSS4JInInterceptor,
>>> > > etc.
>>> > >
>>> > > I'm going to validate this approach with JBoss CXF. If you have any
>>> > > comments
>>> > > then please let me know.
>>> > >
>>> > > I think we may have a simpler alternative eventually to the way
>>> > > authorization decisions are made. [1]-[3] is specific to ws-security,
>>> but
>>> > > [4]-[5] is not
>>> > >
>>> > > cheers, Sergey
>>> > >
>>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
>>> > > [2]
>>> > >
>>> > >
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
>>> > > g/a
>>> > >
>>> > >
>>> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
>>> > > tor<
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
>>> > >
>>> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
>>> > > ngInterceptor> .java
>>> > > [3]
>>> > >
>>> > >
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
>>> > > g/a
>>> > >
>>> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
>>> > > /
>>> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
>>> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
>>> [4]
>>> > >
>>> > >
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>> > > e/c
>>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
>>> http://svn
>>> > > .
>>> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
>>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
>>> > >
>>> > >
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>> > > e/c
>>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
>>> http://svn.apa
>>> > >
>>> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
>>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>>
>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
I'll add a system test in the next few days, the test will rely on the CXF
UsernameTokenInterceptor subclass and mock UsernameTokenProcessor, just to
demonstrate how it can work...But with a Wss4j patch applied it would be
even simpler
cheers, Sergey
On Mon, Apr 19, 2010 at 2:14 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> By the way, the idea (suggested by Dan) to have WSS4J not doing
> UsernameToken processing still works with the proposed patch. But I'd rather
> have a NoopProcessor added to CXF and registered with WSS4J when needed to
> delegate the processing of token/actions to interceptors like
> UsernameTokenInterceptor...
>
> thanks, Sergey
>
>
> On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
>
>> Hi
>>
>> I've added an initial patch for addressing a policy-first case, see [1].
>> It's a patch because it depends on another one I submitted to WSS4J [2].
>> Both patches need more work (tests, etc) but I'd just like to initiate a
>> discussion/review.
>>
>> The idea behind [1] is quite similar to the one used in supporting a
>> java-first case, where a custom interceptor extends an
>> AbstractWSS4JSecurityContextPr
>> oviding interceptor. But is is much simpler in [1] where
>> UsernameTokenProcessor may be optionally extended and its createSubject
>> method be overridden. Provided [2] gets applied then a subclass will just
>> have a property set disabling the (WSS4J) validation of passwords and will
>> do its own validation in createSubject method.
>>
>> This is really all what will be needed in simple cases, where a
>> DefaultSecurityContext will do, but optionally, createSecurityContext can
>> be overridden too.
>>
>> A user would need to set a bus property
>> "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a custom
>> interceptor which will indicate to the WSSecurityPolicyLoader that a custom
>> UsernameTokenProcessor subclass will need to be loaded.
>>
>> Similar approach can be employed for handling other types of tokens.
>>
>> cheers, Sergey
>>
>> [1] https://issues.apache.org/jira/browse/CXF-2754
>> [2] https://issues.apache.org/jira/browse/WSS-229
>>
>>
>> On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
>>
>>> Just realized I did not CC tp dev when replying to Dan the other day :
>>>
>>> Hi Dan
>>>
>>>
>>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>>
>>>> My main "concern" with the implementation of this is that it's done as a
>>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>>> the
>>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>>> as
>>>> well.
>>>>
>>>> I think the better approach may be to add a flag to wss4j (I can help
>>>> commit
>>>> changes there if needed) to have it not do any UserName token processing
>>>> at
>>>> all. (aside: this may be doable without changes to wss4j by
>>>> registering our
>>>> own "do nothing processor") Then, have another interceptor that runs
>>>> after
>>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>>> verify
>>>> anything it needs and such.
>>>>
>>>
>>> This sounds like a very good idea, I agree the proposed approach won't do
>>> for the cases where policies drive the
>>> creation of interceptors.
>>>
>>> Having said that, I think the abstract utility interceptor extending
>>> WSS4JInInterceptor
>>> may still be used in cases where users start from manually configuring
>>> jaxws endpoints. In these cases they'd need to
>>> list up to 3 interceptors (the one which extends
>>> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if the
>>> authorization is needed plus may be a SAAJ one) but otherwise, when say a
>>> clear text password has been encrypted, they'd still need to specify
>>> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
>>> UsernameTokenInterceptor, etc.
>>>
>>> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit complicated
>>> due to the fact it blocks the WSS4J digest checks and thus also creates a
>>> security engine per every request, but it all will be gone in due time...
>>>
>>>
>>>>
>>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>>> There is
>>>> currently some duplicated code between the
>>>> PolicyBasedWSS4JIinInterceptor and
>>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>>> that
>>>> completely to the UsernameTokenInterceptor.
>>>>
>>>
>>> What I will do is I will experiment with the test you added (thanks :-))
>>> and see how UsernameTokenInterceptor can be refactored
>>> so that a subclass can get an easy access to password, nonce, etc. I
>>> think I will need to come up with a contextual property so that a custom
>>> UsernameTokenInterceptor can be installed if needed. Or may be
>>> UsernameTokenInterceptor can store the details in a message to be later
>>> retrieved and processed for creating SecurityContext - but I'm not sure
>>> about it just yet.
>>>
>>>
>>>>
>>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>>> encryption/signature stuff and then let the authorization validations
>>>> stuff to
>>>> later interceptors. That would include things like key validation
>>>> checking
>>>> and stuff as well. Probably SAML token validation as well.
>>>>
>>>>
>>> sounds good
>>>
>>> cheers, Sergey
>>>
>>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>>
>>>>
>>>> My main "concern" with the implementation of this is that it's done as a
>>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>>> the
>>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>>> as
>>>> well.
>>>>
>>>> I think the better approach may be to add a flag to wss4j (I can help
>>>> commit
>>>> changes there if needed) to have it not do any UserName token processing
>>>> at
>>>> all. (aside: this may be doable without changes to wss4j by
>>>> registering our
>>>> own "do nothing processor") Then, have another interceptor that runs
>>>> after
>>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>>> verify
>>>> anything it needs and such.
>>>>
>>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>>> There is
>>>> currently some duplicated code between the
>>>> PolicyBasedWSS4JIinInterceptor and
>>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>>> that
>>>> completely to the UsernameTokenInterceptor.
>>>>
>>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>>> encryption/signature stuff and then let the authorization validations
>>>> stuff to
>>>> later interceptors. That would include things like key validation
>>>> checking
>>>> and stuff as well. Probably SAML token validation as well.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
>>>> > Hi David
>>>> >
>>>> > thanks for the comments...
>>>> >
>>>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
>>>> wrote:
>>>> > > Sergey,
>>>> > >
>>>> > > I think this type of functionality would be very useful to a number
>>>> of
>>>> > > folks. I have built two similar capabilities for clients very
>>>> recently
>>>> > > using CXF and Spring Security. Based on the code provided below, I
>>>> have
>>>> > > several points that I would like to see addressed in a solution.
>>>> > >
>>>> > > 1) Architecture to support more than just UsernameTokens. I have
>>>> worked
>>>> > > with systems that need to authenticate a user using UsernameTokens,
>>>> > > BinarySecurityTokens, SAML Assertions, and a combination of more
>>>> than one
>>>> > > of
>>>> > > these at a time.
>>>> >
>>>> > Supporting UsernameTokens is the initial requirement. At the moment I
>>>> do
>>>> > not even know how BinarySecurityTokens or SAML Assertions are
>>>> > processed/validated in CXF or WSS4J.
>>>> >
>>>> > > For the most part, WSS4J simply validates the structural
>>>> > > details of security. That is, signature validity, trust chaining of
>>>> > > digital
>>>> > > certificates, etc. As Glen pointed out with his reference to
>>>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
>>>> performs
>>>> > > its
>>>> > > own password checking (authentication). Unfortunately, WSS4J
>>>> doesn't
>>>> > > provide hooks for authenticating other forms of credentials that I
>>>> have
>>>> > > listed above (I don't consider trust to be equivalent to
>>>> authentication).
>>>> > > It would be best if the authentication interface supported multiple
>>>> > > credential types and allowed for authentication to be performed in a
>>>> > > single location in the same manner every time (not sometimes in the
>>>> > > WSS4J callback and sometimes in another interceptor for non-UT based
>>>> > > credentials).
>>>> >
>>>> > Makes sense. Assuming it is WSS4J which validates (the structure of)
>>>> > BinarySecurityTokens then
>>>> AbstractWSS4JSecurityContextProvidingInterceptor
>>>> > can also implement a processor for BinarySecurityTokens and delegate
>>>> to
>>>> > subclass to authenticate and setup a subject. Some extra methods will
>>>> need
>>>> > to be added, to be optionally overridden.
>>>> >
>>>> > If it is not only WSS4J which is involved then perhaps another option
>>>> is to
>>>> > store (from WSS4J callback handler, etc) relevant details such
>>>> username
>>>> > token details, etc to be acted upon by other interceptors.
>>>> >
>>>> > > That
>>>> > > last bit there means disabling WSS4J's password authentication since
>>>> it
>>>> > > gets
>>>> > > in the way of doing it later in our own interceptor.
>>>> >
>>>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
>>>> > implementing a simplified UsernameTokenProcessor
>>>> >
>>>> > > 2) Allow for end-user flexibility in choosing the credentials they
>>>> want
>>>> > > to authenticate. For instance, each user is going to have their own
>>>> > > security profiles and authentication requirements. For instance, a
>>>> > > message contains a UT for a portal user and a digital signature from
>>>> the
>>>> > > portal (I know using
>>>> > > a SAML Assertion would be better here, but people still do it this
>>>> way).
>>>> > > Each organization will have different requirements as to which
>>>> > > credentials get authenticated and what needs to end up in the
>>>> security
>>>> > > context.
>>>> >
>>>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
>>>> > should be able to do it, for username tokens and other tokens later
>>>> on.
>>>> >
>>>> > > 3) Decouple the authentication interface from WSS4J. What is passed
>>>> in
>>>> > > needs to be abstracted enough that it can work with other
>>>> WS-Security
>>>> > > libraries as well.
>>>> >
>>>> > the only WSS4J class which is leaked at the moment is
>>>> WSSecurityException.
>>>> > Perhaps we can come up later on with a different more generic approach
>>>> > which does not depend on WSS4J at all. As Dan indicated, in some cases
>>>> > WSS4JInInterceptor is not even used, so that case will need to be
>>>> > addressed. Experimenting wuth binary tokens might help with
>>>> identifying
>>>> > another solution.
>>>> >
>>>> > > 4) It would be nice to be able to perform authorization using
>>>> something
>>>> > > like
>>>> > > Spring Security at the service operation level. With a POJO or
>>>> JAX-WS
>>>> > > based
>>>> > > service, one can just use Spring Security's method interceptor to
>>>> provide
>>>> > > such security; however, in situations where one only has a WSDL
>>>> based
>>>> > > service or a provider style service, a method interceptor can't be
>>>> used.
>>>> > >
>>>> > > It
>>>> > >
>>>> > > would be nice to provide a hook into Spring Security to allow
>>>> end-users
>>>> > > to specify role based authorization policy based on a combination of
>>>> > > interface,
>>>> > > instance, and operation names. It seems like your
>>>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
>>>> > > looking in this direction, but I think it would be best if we can
>>>> stand
>>>> > > on the shoulders of the Spring Security giant as much as possible so
>>>> > > that we can take advantage of their rich authorization manager,
>>>> voter,
>>>> > > XML
>>>> > > configuration
>>>> > > capabilities.
>>>> >
>>>> > Not sure what to say here yet. But I think non-Spring users should be
>>>> taken
>>>> > care of too. Or when simpler cases are dealt with then perhaps there's
>>>> no
>>>> > need to bring in Spring security. Perhaps the utility authorization
>>>> > interceptors should just not be used when Spring Security is preferred
>>>> ?
>>>> >
>>>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
>>>> CXF-BC
>>>> > > currently has a limited capability to select the credentials to
>>>> > > authenticate
>>>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
>>>> delegates
>>>> > > authentication to the JBI container through a ServiceMix components
>>>> > > authentication service abstraction of JAAS. Whatever solution we
>>>> have
>>>> > > for 1
>>>> > > and 2 would help out the component if the ServiceMix authentication
>>>> > > service abstraction could be wired up in lieu of whatever we provide
>>>> out
>>>> > > of the box.
>>>> >
>>>> > I'm not planning to contribute to ServiceMix. I agree though that an
>>>> ideal
>>>> > solution will meet multiple requirements
>>>> >
>>>> > thanks, Sergey
>>>> >
>>>> > > -----Original Message-----
>>>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>>>> > > Sent: Wednesday, April 07, 2010 10:11 AM
>>>> > > To: dev@cxf.apache.org
>>>> > > Subject: Using WS-Security UsernameToken to authenticate users and
>>>> > > populate SecurityContexts
>>>> > >
>>>> > > Hi
>>>> > >
>>>> > > I've been looking recently at extending the CXF WS-Security
>>>> component
>>>> > > such that a current UsernameToken could be used by custom
>>>> interceptors
>>>> > > to authenticate a user with the external security systems and, if
>>>> > > possible, provide enough information for CXF to populate a
>>>> > > SecurityContext [1] to be used later on for
>>>> > > authorization decisions.
>>>> > >
>>>> > > Here is the approach I've taken so far.
>>>> > > A custom interceptor extends
>>>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
>>>> method
>>>> > > it overrides is
>>>> > >
>>>> > > abstract Subject createSubject(String name, String password, boolean
>>>> > > isDigest,
>>>> > >
>>>> > > String nonce,
>>>> > > String created) throws
>>>> > >
>>>> > > WSSecurityException;
>>>> > >
>>>> > >
>>>> > > For example, see [3].
>>>> > >
>>>> > > The idea here is that a custom interceptor interfaces whichever way
>>>> it
>>>> > > needs
>>>> > > to with the external system and populates a Subject following this
>>>> simple
>>>> > > rule : first Subject principal is the current user (identified by a
>>>> > > 'name' argument), followed by one or more Groups this user is a
>>>> member
>>>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
>>>> > > Subject to provide a functional SecurityContext instance.
>>>> > >
>>>> > > This is the first part, next is how to utilize a SecurityContext and
>>>> get
>>>> > > the
>>>> > > expected roles associated one way or the other with a current method
>>>> to
>>>> > > be invoked. There's a number of usual options available here,
>>>> perhaps
>>>> > > even SpringSecurity can be used now that SecurityContext is
>>>> available,
>>>> > > or application code or other custom CXF interceptor can check the
>>>> known
>>>> > > roles against SecurityContext.
>>>> > >
>>>> > > I've also added AbstractAuthorizingInInterceptor interceptor which
>>>> custom
>>>> > > interceptors can override and return a list of expected roles given
>>>> a
>>>> > > (service) Method to be invoked upon,
>>>> AbstractAuthorizingInInterceptor
>>>> > > will then ask available SecurityContext to match the roles; one
>>>> concrete
>>>> > > implementation is SimpleAuthorizingInterceptor[5], it can be
>>>> injected
>>>> > > with a
>>>> > > method specific or class (applying to all methods) roles. Another
>>>> > > implementation which I will likely add later on will be injected
>>>> with a
>>>> > > name
>>>> > > of annotation such as RolesAlloved and it will introspect a method
>>>> and
>>>> > > its class.
>>>> > >
>>>> > > Note that I haven't looked into the case when a policy runtimes adds
>>>> the
>>>> > > interceptors yet (as opposed to interceptors being configured form
>>>> > > Spring/programmatically). I think an optional contextual property
>>>> will
>>>> > > need to be setup in such cases for users be able to indicate that
>>>> say an
>>>> > > interceptor such as [3] has to be used as opposed to
>>>> WSS4JInInterceptor,
>>>> > > etc.
>>>> > >
>>>> > > I'm going to validate this approach with JBoss CXF. If you have any
>>>> > > comments
>>>> > > then please let me know.
>>>> > >
>>>> > > I think we may have a simpler alternative eventually to the way
>>>> > > authorization decisions are made. [1]-[3] is specific to
>>>> ws-security, but
>>>> > > [4]-[5] is not
>>>> > >
>>>> > > cheers, Sergey
>>>> > >
>>>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
>>>> > > [2]
>>>> > >
>>>> > >
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
>>>> > > g/a
>>>> > >
>>>> > >
>>>> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
>>>> > > tor<
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
>>>> > >
>>>> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
>>>> > > ngInterceptor> .java
>>>> > > [3]
>>>> > >
>>>> > >
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
>>>> > > g/a
>>>> > >
>>>> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
>>>> > > /
>>>> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
>>>> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
>>>> [4]
>>>> > >
>>>> > >
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>>> > > e/c
>>>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
>>>> http://svn
>>>> > > .
>>>> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
>>>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
>>>> > >
>>>> > >
>>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>>> > > e/c
>>>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
>>>> http://svn.apa
>>>> > >
>>>> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
>>>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>>>>
>>>> --
>>>> Daniel Kulp
>>>> dkulp@apache.org
>>>> http://dankulp.com/blog
>>>>
>>>
>>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
By the way, the idea (suggested by Dan) to have WSS4J not doing
UsernameToken processing still works with the proposed patch. But I'd rather
have a NoopProcessor added to CXF and registered with WSS4J when needed to
delegate the processing of token/actions to interceptors like
UsernameTokenInterceptor...
thanks, Sergey
On Mon, Apr 19, 2010 at 1:46 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi
>
> I've added an initial patch for addressing a policy-first case, see [1].
> It's a patch because it depends on another one I submitted to WSS4J [2].
> Both patches need more work (tests, etc) but I'd just like to initiate a
> discussion/review.
>
> The idea behind [1] is quite similar to the one used in supporting a
> java-first case, where a custom interceptor extends an
> AbstractWSS4JSecurityContextPr
> oviding interceptor. But is is much simpler in [1] where
> UsernameTokenProcessor may be optionally extended and its createSubject
> method be overridden. Provided [2] gets applied then a subclass will just
> have a property set disabling the (WSS4J) validation of passwords and will
> do its own validation in createSubject method.
>
> This is really all what will be needed in simple cases, where a
> DefaultSecurityContext will do, but optionally, createSecurityContext can
> be overridden too.
>
> A user would need to set a bus property
> "org.apache.cxf.ws.security.usernametoken.interceptor" referincing a custom
> interceptor which will indicate to the WSSecurityPolicyLoader that a custom
> UsernameTokenProcessor subclass will need to be loaded.
>
> Similar approach can be employed for handling other types of tokens.
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/CXF-2754
> [2] https://issues.apache.org/jira/browse/WSS-229
>
>
> On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
>
>> Just realized I did not CC tp dev when replying to Dan the other day :
>>
>> Hi Dan
>>
>>
>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> My main "concern" with the implementation of this is that it's done as a
>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>> the
>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>> as
>>> well.
>>>
>>> I think the better approach may be to add a flag to wss4j (I can help
>>> commit
>>> changes there if needed) to have it not do any UserName token processing
>>> at
>>> all. (aside: this may be doable without changes to wss4j by
>>> registering our
>>> own "do nothing processor") Then, have another interceptor that runs
>>> after
>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>> verify
>>> anything it needs and such.
>>>
>>
>> This sounds like a very good idea, I agree the proposed approach won't do
>> for the cases where policies drive the
>> creation of interceptors.
>>
>> Having said that, I think the abstract utility interceptor extending
>> WSS4JInInterceptor
>> may still be used in cases where users start from manually configuring
>> jaxws endpoints. In these cases they'd need to
>> list up to 3 interceptors (the one which extends
>> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if the
>> authorization is needed plus may be a SAAJ one) but otherwise, when say a
>> clear text password has been encrypted, they'd still need to specify
>> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
>> UsernameTokenInterceptor, etc.
>>
>> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit complicated
>> due to the fact it blocks the WSS4J digest checks and thus also creates a
>> security engine per every request, but it all will be gone in due time...
>>
>>
>>>
>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>> There is
>>> currently some duplicated code between the PolicyBasedWSS4JIinInterceptor
>>> and
>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>> that
>>> completely to the UsernameTokenInterceptor.
>>>
>>
>> What I will do is I will experiment with the test you added (thanks :-))
>> and see how UsernameTokenInterceptor can be refactored
>> so that a subclass can get an easy access to password, nonce, etc. I think
>> I will need to come up with a contextual property so that a custom
>> UsernameTokenInterceptor can be installed if needed. Or may be
>> UsernameTokenInterceptor can store the details in a message to be later
>> retrieved and processed for creating SecurityContext - but I'm not sure
>> about it just yet.
>>
>>
>>>
>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>> encryption/signature stuff and then let the authorization validations
>>> stuff to
>>> later interceptors. That would include things like key validation
>>> checking
>>> and stuff as well. Probably SAML token validation as well.
>>>
>>>
>> sounds good
>>
>> cheers, Sergey
>>
>> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>>>
>>> My main "concern" with the implementation of this is that it's done as a
>>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>>> the
>>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>>> as
>>> well.
>>>
>>> I think the better approach may be to add a flag to wss4j (I can help
>>> commit
>>> changes there if needed) to have it not do any UserName token processing
>>> at
>>> all. (aside: this may be doable without changes to wss4j by
>>> registering our
>>> own "do nothing processor") Then, have another interceptor that runs
>>> after
>>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>>> verify
>>> anything it needs and such.
>>>
>>> To be honest, I WANT to do this for the Policy based stuff anyway.
>>> There is
>>> currently some duplicated code between the PolicyBasedWSS4JIinInterceptor
>>> and
>>> the new UsernameTokenInterceptor that could be eliminated by having the
>>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>>> that
>>> completely to the UsernameTokenInterceptor.
>>>
>>> Basically, it would be good if the WSS4JIn* stuff just handled the
>>> encryption/signature stuff and then let the authorization validations
>>> stuff to
>>> later interceptors. That would include things like key validation
>>> checking
>>> and stuff as well. Probably SAML token validation as well.
>>>
>>> Dan
>>>
>>>
>>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
>>> > Hi David
>>> >
>>> > thanks for the comments...
>>> >
>>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
>>> wrote:
>>> > > Sergey,
>>> > >
>>> > > I think this type of functionality would be very useful to a number
>>> of
>>> > > folks. I have built two similar capabilities for clients very
>>> recently
>>> > > using CXF and Spring Security. Based on the code provided below, I
>>> have
>>> > > several points that I would like to see addressed in a solution.
>>> > >
>>> > > 1) Architecture to support more than just UsernameTokens. I have
>>> worked
>>> > > with systems that need to authenticate a user using UsernameTokens,
>>> > > BinarySecurityTokens, SAML Assertions, and a combination of more than
>>> one
>>> > > of
>>> > > these at a time.
>>> >
>>> > Supporting UsernameTokens is the initial requirement. At the moment I
>>> do
>>> > not even know how BinarySecurityTokens or SAML Assertions are
>>> > processed/validated in CXF or WSS4J.
>>> >
>>> > > For the most part, WSS4J simply validates the structural
>>> > > details of security. That is, signature validity, trust chaining of
>>> > > digital
>>> > > certificates, etc. As Glen pointed out with his reference to
>>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
>>> performs
>>> > > its
>>> > > own password checking (authentication). Unfortunately, WSS4J doesn't
>>> > > provide hooks for authenticating other forms of credentials that I
>>> have
>>> > > listed above (I don't consider trust to be equivalent to
>>> authentication).
>>> > > It would be best if the authentication interface supported multiple
>>> > > credential types and allowed for authentication to be performed in a
>>> > > single location in the same manner every time (not sometimes in the
>>> > > WSS4J callback and sometimes in another interceptor for non-UT based
>>> > > credentials).
>>> >
>>> > Makes sense. Assuming it is WSS4J which validates (the structure of)
>>> > BinarySecurityTokens then
>>> AbstractWSS4JSecurityContextProvidingInterceptor
>>> > can also implement a processor for BinarySecurityTokens and delegate to
>>> > subclass to authenticate and setup a subject. Some extra methods will
>>> need
>>> > to be added, to be optionally overridden.
>>> >
>>> > If it is not only WSS4J which is involved then perhaps another option
>>> is to
>>> > store (from WSS4J callback handler, etc) relevant details such username
>>> > token details, etc to be acted upon by other interceptors.
>>> >
>>> > > That
>>> > > last bit there means disabling WSS4J's password authentication since
>>> it
>>> > > gets
>>> > > in the way of doing it later in our own interceptor.
>>> >
>>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
>>> > implementing a simplified UsernameTokenProcessor
>>> >
>>> > > 2) Allow for end-user flexibility in choosing the credentials they
>>> want
>>> > > to authenticate. For instance, each user is going to have their own
>>> > > security profiles and authentication requirements. For instance, a
>>> > > message contains a UT for a portal user and a digital signature from
>>> the
>>> > > portal (I know using
>>> > > a SAML Assertion would be better here, but people still do it this
>>> way).
>>> > > Each organization will have different requirements as to which
>>> > > credentials get authenticated and what needs to end up in the
>>> security
>>> > > context.
>>> >
>>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
>>> > should be able to do it, for username tokens and other tokens later on.
>>> >
>>> > > 3) Decouple the authentication interface from WSS4J. What is passed
>>> in
>>> > > needs to be abstracted enough that it can work with other WS-Security
>>> > > libraries as well.
>>> >
>>> > the only WSS4J class which is leaked at the moment is
>>> WSSecurityException.
>>> > Perhaps we can come up later on with a different more generic approach
>>> > which does not depend on WSS4J at all. As Dan indicated, in some cases
>>> > WSS4JInInterceptor is not even used, so that case will need to be
>>> > addressed. Experimenting wuth binary tokens might help with identifying
>>> > another solution.
>>> >
>>> > > 4) It would be nice to be able to perform authorization using
>>> something
>>> > > like
>>> > > Spring Security at the service operation level. With a POJO or
>>> JAX-WS
>>> > > based
>>> > > service, one can just use Spring Security's method interceptor to
>>> provide
>>> > > such security; however, in situations where one only has a WSDL based
>>> > > service or a provider style service, a method interceptor can't be
>>> used.
>>> > >
>>> > > It
>>> > >
>>> > > would be nice to provide a hook into Spring Security to allow
>>> end-users
>>> > > to specify role based authorization policy based on a combination of
>>> > > interface,
>>> > > instance, and operation names. It seems like your
>>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
>>> > > looking in this direction, but I think it would be best if we can
>>> stand
>>> > > on the shoulders of the Spring Security giant as much as possible so
>>> > > that we can take advantage of their rich authorization manager,
>>> voter,
>>> > > XML
>>> > > configuration
>>> > > capabilities.
>>> >
>>> > Not sure what to say here yet. But I think non-Spring users should be
>>> taken
>>> > care of too. Or when simpler cases are dealt with then perhaps there's
>>> no
>>> > need to bring in Spring security. Perhaps the utility authorization
>>> > interceptors should just not be used when Spring Security is preferred
>>> ?
>>> >
>>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The
>>> CXF-BC
>>> > > currently has a limited capability to select the credentials to
>>> > > authenticate
>>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately
>>> delegates
>>> > > authentication to the JBI container through a ServiceMix components
>>> > > authentication service abstraction of JAAS. Whatever solution we
>>> have
>>> > > for 1
>>> > > and 2 would help out the component if the ServiceMix authentication
>>> > > service abstraction could be wired up in lieu of whatever we provide
>>> out
>>> > > of the box.
>>> >
>>> > I'm not planning to contribute to ServiceMix. I agree though that an
>>> ideal
>>> > solution will meet multiple requirements
>>> >
>>> > thanks, Sergey
>>> >
>>> > > -----Original Message-----
>>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>>> > > Sent: Wednesday, April 07, 2010 10:11 AM
>>> > > To: dev@cxf.apache.org
>>> > > Subject: Using WS-Security UsernameToken to authenticate users and
>>> > > populate SecurityContexts
>>> > >
>>> > > Hi
>>> > >
>>> > > I've been looking recently at extending the CXF WS-Security component
>>> > > such that a current UsernameToken could be used by custom
>>> interceptors
>>> > > to authenticate a user with the external security systems and, if
>>> > > possible, provide enough information for CXF to populate a
>>> > > SecurityContext [1] to be used later on for
>>> > > authorization decisions.
>>> > >
>>> > > Here is the approach I've taken so far.
>>> > > A custom interceptor extends
>>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
>>> method
>>> > > it overrides is
>>> > >
>>> > > abstract Subject createSubject(String name, String password, boolean
>>> > > isDigest,
>>> > >
>>> > > String nonce,
>>> > > String created) throws
>>> > >
>>> > > WSSecurityException;
>>> > >
>>> > >
>>> > > For example, see [3].
>>> > >
>>> > > The idea here is that a custom interceptor interfaces whichever way
>>> it
>>> > > needs
>>> > > to with the external system and populates a Subject following this
>>> simple
>>> > > rule : first Subject principal is the current user (identified by a
>>> > > 'name' argument), followed by one or more Groups this user is a
>>> member
>>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
>>> > > Subject to provide a functional SecurityContext instance.
>>> > >
>>> > > This is the first part, next is how to utilize a SecurityContext and
>>> get
>>> > > the
>>> > > expected roles associated one way or the other with a current method
>>> to
>>> > > be invoked. There's a number of usual options available here, perhaps
>>> > > even SpringSecurity can be used now that SecurityContext is
>>> available,
>>> > > or application code or other custom CXF interceptor can check the
>>> known
>>> > > roles against SecurityContext.
>>> > >
>>> > > I've also added AbstractAuthorizingInInterceptor interceptor which
>>> custom
>>> > > interceptors can override and return a list of expected roles given a
>>> > > (service) Method to be invoked upon, AbstractAuthorizingInInterceptor
>>> > > will then ask available SecurityContext to match the roles; one
>>> concrete
>>> > > implementation is SimpleAuthorizingInterceptor[5], it can be injected
>>> > > with a
>>> > > method specific or class (applying to all methods) roles. Another
>>> > > implementation which I will likely add later on will be injected with
>>> a
>>> > > name
>>> > > of annotation such as RolesAlloved and it will introspect a method
>>> and
>>> > > its class.
>>> > >
>>> > > Note that I haven't looked into the case when a policy runtimes adds
>>> the
>>> > > interceptors yet (as opposed to interceptors being configured form
>>> > > Spring/programmatically). I think an optional contextual property
>>> will
>>> > > need to be setup in such cases for users be able to indicate that say
>>> an
>>> > > interceptor such as [3] has to be used as opposed to
>>> WSS4JInInterceptor,
>>> > > etc.
>>> > >
>>> > > I'm going to validate this approach with JBoss CXF. If you have any
>>> > > comments
>>> > > then please let me know.
>>> > >
>>> > > I think we may have a simpler alternative eventually to the way
>>> > > authorization decisions are made. [1]-[3] is specific to ws-security,
>>> but
>>> > > [4]-[5] is not
>>> > >
>>> > > cheers, Sergey
>>> > >
>>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
>>> > > [2]
>>> > >
>>> > >
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
>>> > > g/a
>>> > >
>>> > >
>>> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
>>> > > tor<
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
>>> > >
>>> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
>>> > > ngInterceptor> .java
>>> > > [3]
>>> > >
>>> > >
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
>>> > > g/a
>>> > >
>>> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
>>> > > /
>>> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
>>> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
>>> [4]
>>> > >
>>> > >
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>> > > e/c
>>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
>>> http://svn
>>> > > .
>>> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
>>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
>>> > >
>>> > >
>>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>>> > > e/c
>>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
>>> http://svn.apa
>>> > >
>>> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
>>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org
>>> http://dankulp.com/blog
>>>
>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
I've added an initial patch for addressing a policy-first case, see [1].
It's a patch because it depends on another one I submitted to WSS4J [2].
Both patches need more work (tests, etc) but I'd just like to initiate a
discussion/review.
The idea behind [1] is quite similar to the one used in supporting a
java-first case, where a custom interceptor extends an
AbstractWSS4JSecurityContextPr
oviding interceptor. But is is much simpler in [1] where
UsernameTokenProcessor may be optionally extended and its createSubject
method be overridden. Provided [2] gets applied then a subclass will just
have a property set disabling the (WSS4J) validation of passwords and will
do its own validation in createSubject method.
This is really all what will be needed in simple cases, where a
DefaultSecurityContext will do, but optionally, createSecurityContext can
be overridden too.
A user would need to set a bus property
"org.apache.cxf.ws.security.usernametoken.interceptor" referincing a custom
interceptor which will indicate to the WSSecurityPolicyLoader that a custom
UsernameTokenProcessor subclass will need to be loaded.
Similar approach can be employed for handling other types of tokens.
cheers, Sergey
[1] https://issues.apache.org/jira/browse/CXF-2754
[2] https://issues.apache.org/jira/browse/WSS-229
On Mon, Apr 19, 2010 at 1:43 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Just realized I did not CC tp dev when replying to Dan the other day :
>
> Hi Dan
>
>
> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> My main "concern" with the implementation of this is that it's done as a
>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>> the
>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>> as
>> well.
>>
>> I think the better approach may be to add a flag to wss4j (I can help
>> commit
>> changes there if needed) to have it not do any UserName token processing
>> at
>> all. (aside: this may be doable without changes to wss4j by registering
>> our
>> own "do nothing processor") Then, have another interceptor that runs
>> after
>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>> verify
>> anything it needs and such.
>>
>
> This sounds like a very good idea, I agree the proposed approach won't do
> for the cases where policies drive the
> creation of interceptors.
>
> Having said that, I think the abstract utility interceptor extending
> WSS4JInInterceptor
> may still be used in cases where users start from manually configuring
> jaxws endpoints. In these cases they'd need to
> list up to 3 interceptors (the one which extends
> AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if the
> authorization is needed plus may be a SAAJ one) but otherwise, when say a
> clear text password has been encrypted, they'd still need to specify
> WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
> UsernameTokenInterceptor, etc.
>
> At the moment AbstractWSS4JSecuriyContextInterceptor is a bit complicated
> due to the fact it blocks the WSS4J digest checks and thus also creates a
> security engine per every request, but it all will be gone in due time...
>
>
>>
>> To be honest, I WANT to do this for the Policy based stuff anyway. There
>> is
>> currently some duplicated code between the PolicyBasedWSS4JIinInterceptor
>> and
>> the new UsernameTokenInterceptor that could be eliminated by having the
>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>> that
>> completely to the UsernameTokenInterceptor.
>>
>
> What I will do is I will experiment with the test you added (thanks :-))
> and see how UsernameTokenInterceptor can be refactored
> so that a subclass can get an easy access to password, nonce, etc. I think
> I will need to come up with a contextual property so that a custom
> UsernameTokenInterceptor can be installed if needed. Or may be
> UsernameTokenInterceptor can store the details in a message to be later
> retrieved and processed for creating SecurityContext - but I'm not sure
> about it just yet.
>
>
>>
>> Basically, it would be good if the WSS4JIn* stuff just handled the
>> encryption/signature stuff and then let the authorization validations
>> stuff to
>> later interceptors. That would include things like key validation
>> checking
>> and stuff as well. Probably SAML token validation as well.
>>
>>
> sounds good
>
> cheers, Sergey
>
> On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>>
>> My main "concern" with the implementation of this is that it's done as a
>> direct subclass of the WSS4JInInterceptor and thus not really usable by
>> the
>> policy based endpoints as those interceptors subclass WSS4JInInterceptor
>> as
>> well.
>>
>> I think the better approach may be to add a flag to wss4j (I can help
>> commit
>> changes there if needed) to have it not do any UserName token processing
>> at
>> all. (aside: this may be doable without changes to wss4j by registering
>> our
>> own "do nothing processor") Then, have another interceptor that runs
>> after
>> the WSS4JInInterceptor that would actually handle the UsernameToken and
>> verify
>> anything it needs and such.
>>
>> To be honest, I WANT to do this for the Policy based stuff anyway. There
>> is
>> currently some duplicated code between the PolicyBasedWSS4JIinInterceptor
>> and
>> the new UsernameTokenInterceptor that could be eliminated by having the
>> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
>> that
>> completely to the UsernameTokenInterceptor.
>>
>> Basically, it would be good if the WSS4JIn* stuff just handled the
>> encryption/signature stuff and then let the authorization validations
>> stuff to
>> later interceptors. That would include things like key validation
>> checking
>> and stuff as well. Probably SAML token validation as well.
>>
>> Dan
>>
>>
>> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
>> > Hi David
>> >
>> > thanks for the comments...
>> >
>> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org>
>> wrote:
>> > > Sergey,
>> > >
>> > > I think this type of functionality would be very useful to a number of
>> > > folks. I have built two similar capabilities for clients very
>> recently
>> > > using CXF and Spring Security. Based on the code provided below, I
>> have
>> > > several points that I would like to see addressed in a solution.
>> > >
>> > > 1) Architecture to support more than just UsernameTokens. I have
>> worked
>> > > with systems that need to authenticate a user using UsernameTokens,
>> > > BinarySecurityTokens, SAML Assertions, and a combination of more than
>> one
>> > > of
>> > > these at a time.
>> >
>> > Supporting UsernameTokens is the initial requirement. At the moment I do
>> > not even know how BinarySecurityTokens or SAML Assertions are
>> > processed/validated in CXF or WSS4J.
>> >
>> > > For the most part, WSS4J simply validates the structural
>> > > details of security. That is, signature validity, trust chaining of
>> > > digital
>> > > certificates, etc. As Glen pointed out with his reference to
>> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
>> performs
>> > > its
>> > > own password checking (authentication). Unfortunately, WSS4J doesn't
>> > > provide hooks for authenticating other forms of credentials that I
>> have
>> > > listed above (I don't consider trust to be equivalent to
>> authentication).
>> > > It would be best if the authentication interface supported multiple
>> > > credential types and allowed for authentication to be performed in a
>> > > single location in the same manner every time (not sometimes in the
>> > > WSS4J callback and sometimes in another interceptor for non-UT based
>> > > credentials).
>> >
>> > Makes sense. Assuming it is WSS4J which validates (the structure of)
>> > BinarySecurityTokens then
>> AbstractWSS4JSecurityContextProvidingInterceptor
>> > can also implement a processor for BinarySecurityTokens and delegate to
>> > subclass to authenticate and setup a subject. Some extra methods will
>> need
>> > to be added, to be optionally overridden.
>> >
>> > If it is not only WSS4J which is involved then perhaps another option is
>> to
>> > store (from WSS4J callback handler, etc) relevant details such username
>> > token details, etc to be acted upon by other interceptors.
>> >
>> > > That
>> > > last bit there means disabling WSS4J's password authentication since
>> it
>> > > gets
>> > > in the way of doing it later in our own interceptor.
>> >
>> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
>> > implementing a simplified UsernameTokenProcessor
>> >
>> > > 2) Allow for end-user flexibility in choosing the credentials they
>> want
>> > > to authenticate. For instance, each user is going to have their own
>> > > security profiles and authentication requirements. For instance, a
>> > > message contains a UT for a portal user and a digital signature from
>> the
>> > > portal (I know using
>> > > a SAML Assertion would be better here, but people still do it this
>> way).
>> > > Each organization will have different requirements as to which
>> > > credentials get authenticated and what needs to end up in the security
>> > > context.
>> >
>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
>> > should be able to do it, for username tokens and other tokens later on.
>> >
>> > > 3) Decouple the authentication interface from WSS4J. What is passed
>> in
>> > > needs to be abstracted enough that it can work with other WS-Security
>> > > libraries as well.
>> >
>> > the only WSS4J class which is leaked at the moment is
>> WSSecurityException.
>> > Perhaps we can come up later on with a different more generic approach
>> > which does not depend on WSS4J at all. As Dan indicated, in some cases
>> > WSS4JInInterceptor is not even used, so that case will need to be
>> > addressed. Experimenting wuth binary tokens might help with identifying
>> > another solution.
>> >
>> > > 4) It would be nice to be able to perform authorization using
>> something
>> > > like
>> > > Spring Security at the service operation level. With a POJO or JAX-WS
>> > > based
>> > > service, one can just use Spring Security's method interceptor to
>> provide
>> > > such security; however, in situations where one only has a WSDL based
>> > > service or a provider style service, a method interceptor can't be
>> used.
>> > >
>> > > It
>> > >
>> > > would be nice to provide a hook into Spring Security to allow
>> end-users
>> > > to specify role based authorization policy based on a combination of
>> > > interface,
>> > > instance, and operation names. It seems like your
>> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
>> > > looking in this direction, but I think it would be best if we can
>> stand
>> > > on the shoulders of the Spring Security giant as much as possible so
>> > > that we can take advantage of their rich authorization manager, voter,
>> > > XML
>> > > configuration
>> > > capabilities.
>> >
>> > Not sure what to say here yet. But I think non-Spring users should be
>> taken
>> > care of too. Or when simpler cases are dealt with then perhaps there's
>> no
>> > need to bring in Spring security. Perhaps the utility authorization
>> > interceptors should just not be used when Spring Security is preferred ?
>> >
>> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The CXF-BC
>> > > currently has a limited capability to select the credentials to
>> > > authenticate
>> > > and would benefit from 1 and 2 above. The CXF-BC ultimately delegates
>> > > authentication to the JBI container through a ServiceMix components
>> > > authentication service abstraction of JAAS. Whatever solution we have
>> > > for 1
>> > > and 2 would help out the component if the ServiceMix authentication
>> > > service abstraction could be wired up in lieu of whatever we provide
>> out
>> > > of the box.
>> >
>> > I'm not planning to contribute to ServiceMix. I agree though that an
>> ideal
>> > solution will meet multiple requirements
>> >
>> > thanks, Sergey
>> >
>> > > -----Original Message-----
>> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> > > Sent: Wednesday, April 07, 2010 10:11 AM
>> > > To: dev@cxf.apache.org
>> > > Subject: Using WS-Security UsernameToken to authenticate users and
>> > > populate SecurityContexts
>> > >
>> > > Hi
>> > >
>> > > I've been looking recently at extending the CXF WS-Security component
>> > > such that a current UsernameToken could be used by custom interceptors
>> > > to authenticate a user with the external security systems and, if
>> > > possible, provide enough information for CXF to populate a
>> > > SecurityContext [1] to be used later on for
>> > > authorization decisions.
>> > >
>> > > Here is the approach I've taken so far.
>> > > A custom interceptor extends
>> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
>> method
>> > > it overrides is
>> > >
>> > > abstract Subject createSubject(String name, String password, boolean
>> > > isDigest,
>> > >
>> > > String nonce,
>> > > String created) throws
>> > >
>> > > WSSecurityException;
>> > >
>> > >
>> > > For example, see [3].
>> > >
>> > > The idea here is that a custom interceptor interfaces whichever way it
>> > > needs
>> > > to with the external system and populates a Subject following this
>> simple
>> > > rule : first Subject principal is the current user (identified by a
>> > > 'name' argument), followed by one or more Groups this user is a member
>> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
>> > > Subject to provide a functional SecurityContext instance.
>> > >
>> > > This is the first part, next is how to utilize a SecurityContext and
>> get
>> > > the
>> > > expected roles associated one way or the other with a current method
>> to
>> > > be invoked. There's a number of usual options available here, perhaps
>> > > even SpringSecurity can be used now that SecurityContext is available,
>> > > or application code or other custom CXF interceptor can check the
>> known
>> > > roles against SecurityContext.
>> > >
>> > > I've also added AbstractAuthorizingInInterceptor interceptor which
>> custom
>> > > interceptors can override and return a list of expected roles given a
>> > > (service) Method to be invoked upon, AbstractAuthorizingInInterceptor
>> > > will then ask available SecurityContext to match the roles; one
>> concrete
>> > > implementation is SimpleAuthorizingInterceptor[5], it can be injected
>> > > with a
>> > > method specific or class (applying to all methods) roles. Another
>> > > implementation which I will likely add later on will be injected with
>> a
>> > > name
>> > > of annotation such as RolesAlloved and it will introspect a method and
>> > > its class.
>> > >
>> > > Note that I haven't looked into the case when a policy runtimes adds
>> the
>> > > interceptors yet (as opposed to interceptors being configured form
>> > > Spring/programmatically). I think an optional contextual property will
>> > > need to be setup in such cases for users be able to indicate that say
>> an
>> > > interceptor such as [3] has to be used as opposed to
>> WSS4JInInterceptor,
>> > > etc.
>> > >
>> > > I'm going to validate this approach with JBoss CXF. If you have any
>> > > comments
>> > > then please let me know.
>> > >
>> > > I think we may have a simpler alternative eventually to the way
>> > > authorization decisions are made. [1]-[3] is specific to ws-security,
>> but
>> > > [4]-[5] is not
>> > >
>> > > cheers, Sergey
>> > >
>> > > [1] https://issues.apache.org/jira/browse/CXF-2754
>> > > [2]
>> > >
>> > >
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
>> > > g/a
>> > >
>> > >
>> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
>> > > tor<
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
>> > >
>> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
>> > > ngInterceptor> .java
>> > > [3]
>> > >
>> > >
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
>> > > g/a
>> > >
>> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
>> > > /
>> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
>> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java> [4]
>> > >
>> > >
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>> > > e/c
>> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
>> http://svn
>> > > .
>> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
>> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
>> > >
>> > >
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
>> > > e/c
>> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
>> http://svn.apa
>> > >
>> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
>> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>>
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Just realized I did not CC tp dev when replying to Dan the other day :
Hi Dan
On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> My main "concern" with the implementation of this is that it's done as a
> direct subclass of the WSS4JInInterceptor and thus not really usable by the
> policy based endpoints as those interceptors subclass WSS4JInInterceptor as
> well.
>
> I think the better approach may be to add a flag to wss4j (I can help
> commit
> changes there if needed) to have it not do any UserName token processing at
> all. (aside: this may be doable without changes to wss4j by registering
> our
> own "do nothing processor") Then, have another interceptor that runs
> after
> the WSS4JInInterceptor that would actually handle the UsernameToken and
> verify
> anything it needs and such.
>
This sounds like a very good idea, I agree the proposed approach won't do
for the cases where policies drive the
creation of interceptors.
Having said that, I think the abstract utility interceptor extending
WSS4JInInterceptor
may still be used in cases where users start from manually configuring jaxws
endpoints. In these cases they'd need to
list up to 3 interceptors (the one which extends
AbstractWSS4JSecuriyContextInterceptor, the authorizing interceptor if the
authorization is needed plus may be a SAAJ one) but otherwise, when say a
clear text password has been encrypted, they'd still need to specify
WSS4JInInterceptor (with a flag disabling UsernameToken checks) plus
UsernameTokenInterceptor, etc.
At the moment AbstractWSS4JSecuriyContextInterceptor is a bit complicated
due to the fact it blocks the WSS4J digest checks and thus also creates a
security engine per every request, but it all will be gone in due time...
>
> To be honest, I WANT to do this for the Policy based stuff anyway. There
> is
> currently some duplicated code between the PolicyBasedWSS4JIinInterceptor
> and
> the new UsernameTokenInterceptor that could be eliminated by having the
> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
> that
> completely to the UsernameTokenInterceptor.
>
What I will do is I will experiment with the test you added (thanks :-)) and
see how UsernameTokenInterceptor can be refactored
so that a subclass can get an easy access to password, nonce, etc. I think I
will need to come up with a contextual property so that a custom
UsernameTokenInterceptor can be installed if needed. Or may be
UsernameTokenInterceptor can store the details in a message to be later
retrieved and processed for creating SecurityContext - but I'm not sure
about it just yet.
>
> Basically, it would be good if the WSS4JIn* stuff just handled the
> encryption/signature stuff and then let the authorization validations stuff
> to
> later interceptors. That would include things like key validation
> checking
> and stuff as well. Probably SAML token validation as well.
>
>
sounds good
cheers, Sergey
On Fri, Apr 9, 2010 at 2:50 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> My main "concern" with the implementation of this is that it's done as a
> direct subclass of the WSS4JInInterceptor and thus not really usable by the
> policy based endpoints as those interceptors subclass WSS4JInInterceptor as
> well.
>
> I think the better approach may be to add a flag to wss4j (I can help
> commit
> changes there if needed) to have it not do any UserName token processing at
> all. (aside: this may be doable without changes to wss4j by registering
> our
> own "do nothing processor") Then, have another interceptor that runs
> after
> the WSS4JInInterceptor that would actually handle the UsernameToken and
> verify
> anything it needs and such.
>
> To be honest, I WANT to do this for the Policy based stuff anyway. There
> is
> currently some duplicated code between the PolicyBasedWSS4JIinInterceptor
> and
> the new UsernameTokenInterceptor that could be eliminated by having the
> PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate
> that
> completely to the UsernameTokenInterceptor.
>
> Basically, it would be good if the WSS4JIn* stuff just handled the
> encryption/signature stuff and then let the authorization validations stuff
> to
> later interceptors. That would include things like key validation
> checking
> and stuff as well. Probably SAML token validation as well.
>
> Dan
>
>
> On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
> > Hi David
> >
> > thanks for the comments...
> >
> > On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org> wrote:
> > > Sergey,
> > >
> > > I think this type of functionality would be very useful to a number of
> > > folks. I have built two similar capabilities for clients very recently
> > > using CXF and Spring Security. Based on the code provided below, I
> have
> > > several points that I would like to see addressed in a solution.
> > >
> > > 1) Architecture to support more than just UsernameTokens. I have
> worked
> > > with systems that need to authenticate a user using UsernameTokens,
> > > BinarySecurityTokens, SAML Assertions, and a combination of more than
> one
> > > of
> > > these at a time.
> >
> > Supporting UsernameTokens is the initial requirement. At the moment I do
> > not even know how BinarySecurityTokens or SAML Assertions are
> > processed/validated in CXF or WSS4J.
> >
> > > For the most part, WSS4J simply validates the structural
> > > details of security. That is, signature validity, trust chaining of
> > > digital
> > > certificates, etc. As Glen pointed out with his reference to
> > > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes
> performs
> > > its
> > > own password checking (authentication). Unfortunately, WSS4J doesn't
> > > provide hooks for authenticating other forms of credentials that I have
> > > listed above (I don't consider trust to be equivalent to
> authentication).
> > > It would be best if the authentication interface supported multiple
> > > credential types and allowed for authentication to be performed in a
> > > single location in the same manner every time (not sometimes in the
> > > WSS4J callback and sometimes in another interceptor for non-UT based
> > > credentials).
> >
> > Makes sense. Assuming it is WSS4J which validates (the structure of)
> > BinarySecurityTokens then
> AbstractWSS4JSecurityContextProvidingInterceptor
> > can also implement a processor for BinarySecurityTokens and delegate to
> > subclass to authenticate and setup a subject. Some extra methods will
> need
> > to be added, to be optionally overridden.
> >
> > If it is not only WSS4J which is involved then perhaps another option is
> to
> > store (from WSS4J callback handler, etc) relevant details such username
> > token details, etc to be acted upon by other interceptors.
> >
> > > That
> > > last bit there means disabling WSS4J's password authentication since it
> > > gets
> > > in the way of doing it later in our own interceptor.
> >
> > AbstractWSS4JSecurityContextProvidingInterceptor does it now by
> > implementing a simplified UsernameTokenProcessor
> >
> > > 2) Allow for end-user flexibility in choosing the credentials they want
> > > to authenticate. For instance, each user is going to have their own
> > > security profiles and authentication requirements. For instance, a
> > > message contains a UT for a portal user and a digital signature from
> the
> > > portal (I know using
> > > a SAML Assertion would be better here, but people still do it this
> way).
> > > Each organization will have different requirements as to which
> > > credentials get authenticated and what needs to end up in the security
> > > context.
> >
> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
> > should be able to do it, for username tokens and other tokens later on.
> >
> > > 3) Decouple the authentication interface from WSS4J. What is passed in
> > > needs to be abstracted enough that it can work with other WS-Security
> > > libraries as well.
> >
> > the only WSS4J class which is leaked at the moment is
> WSSecurityException.
> > Perhaps we can come up later on with a different more generic approach
> > which does not depend on WSS4J at all. As Dan indicated, in some cases
> > WSS4JInInterceptor is not even used, so that case will need to be
> > addressed. Experimenting wuth binary tokens might help with identifying
> > another solution.
> >
> > > 4) It would be nice to be able to perform authorization using something
> > > like
> > > Spring Security at the service operation level. With a POJO or JAX-WS
> > > based
> > > service, one can just use Spring Security's method interceptor to
> provide
> > > such security; however, in situations where one only has a WSDL based
> > > service or a provider style service, a method interceptor can't be
> used.
> > >
> > > It
> > >
> > > would be nice to provide a hook into Spring Security to allow end-users
> > > to specify role based authorization policy based on a combination of
> > > interface,
> > > instance, and operation names. It seems like your
> > > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
> > > looking in this direction, but I think it would be best if we can stand
> > > on the shoulders of the Spring Security giant as much as possible so
> > > that we can take advantage of their rich authorization manager, voter,
> > > XML
> > > configuration
> > > capabilities.
> >
> > Not sure what to say here yet. But I think non-Spring users should be
> taken
> > care of too. Or when simpler cases are dealt with then perhaps there's no
> > need to bring in Spring security. Perhaps the utility authorization
> > interceptors should just not be used when Spring Security is preferred ?
> >
> > > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The CXF-BC
> > > currently has a limited capability to select the credentials to
> > > authenticate
> > > and would benefit from 1 and 2 above. The CXF-BC ultimately delegates
> > > authentication to the JBI container through a ServiceMix components
> > > authentication service abstraction of JAAS. Whatever solution we have
> > > for 1
> > > and 2 would help out the component if the ServiceMix authentication
> > > service abstraction could be wired up in lieu of whatever we provide
> out
> > > of the box.
> >
> > I'm not planning to contribute to ServiceMix. I agree though that an
> ideal
> > solution will meet multiple requirements
> >
> > thanks, Sergey
> >
> > > -----Original Message-----
> > > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> > > Sent: Wednesday, April 07, 2010 10:11 AM
> > > To: dev@cxf.apache.org
> > > Subject: Using WS-Security UsernameToken to authenticate users and
> > > populate SecurityContexts
> > >
> > > Hi
> > >
> > > I've been looking recently at extending the CXF WS-Security component
> > > such that a current UsernameToken could be used by custom interceptors
> > > to authenticate a user with the external security systems and, if
> > > possible, provide enough information for CXF to populate a
> > > SecurityContext [1] to be used later on for
> > > authorization decisions.
> > >
> > > Here is the approach I've taken so far.
> > > A custom interceptor extends
> > > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only
> method
> > > it overrides is
> > >
> > > abstract Subject createSubject(String name, String password, boolean
> > > isDigest,
> > >
> > > String nonce,
> > > String created) throws
> > >
> > > WSSecurityException;
> > >
> > >
> > > For example, see [3].
> > >
> > > The idea here is that a custom interceptor interfaces whichever way it
> > > needs
> > > to with the external system and populates a Subject following this
> simple
> > > rule : first Subject principal is the current user (identified by a
> > > 'name' argument), followed by one or more Groups this user is a member
> > > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
> > > Subject to provide a functional SecurityContext instance.
> > >
> > > This is the first part, next is how to utilize a SecurityContext and
> get
> > > the
> > > expected roles associated one way or the other with a current method to
> > > be invoked. There's a number of usual options available here, perhaps
> > > even SpringSecurity can be used now that SecurityContext is available,
> > > or application code or other custom CXF interceptor can check the known
> > > roles against SecurityContext.
> > >
> > > I've also added AbstractAuthorizingInInterceptor interceptor which
> custom
> > > interceptors can override and return a list of expected roles given a
> > > (service) Method to be invoked upon, AbstractAuthorizingInInterceptor
> > > will then ask available SecurityContext to match the roles; one
> concrete
> > > implementation is SimpleAuthorizingInterceptor[5], it can be injected
> > > with a
> > > method specific or class (applying to all methods) roles. Another
> > > implementation which I will likely add later on will be injected with a
> > > name
> > > of annotation such as RolesAlloved and it will introspect a method and
> > > its class.
> > >
> > > Note that I haven't looked into the case when a policy runtimes adds
> the
> > > interceptors yet (as opposed to interceptors being configured form
> > > Spring/programmatically). I think an optional contextual property will
> > > need to be setup in such cases for users be able to indicate that say
> an
> > > interceptor such as [3] has to be used as opposed to
> WSS4JInInterceptor,
> > > etc.
> > >
> > > I'm going to validate this approach with JBoss CXF. If you have any
> > > comments
> > > then please let me know.
> > >
> > > I think we may have a simpler alternative eventually to the way
> > > authorization decisions are made. [1]-[3] is specific to ws-security,
> but
> > > [4]-[5] is not
> > >
> > > cheers, Sergey
> > >
> > > [1] https://issues.apache.org/jira/browse/CXF-2754
> > > [2]
> > >
> > >
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
> > > g/a
> > >
> > >
> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
> > > tor<
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
> > >
> a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
> > > ngInterceptor> .java
> > > [3]
> > >
> > >
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
> > > g/a
> > >
> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
> > > /
> svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
> > > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java> [4]
> > >
> > >
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> > > e/c
> > > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
> http://svn
> > > .
> apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
> > > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
> > >
> > >
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> > > e/c
> > > xf/interceptor/security/SimpleAuthorizingInterceptor.java<
> http://svn.apa
> > >
> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
> > > ceptor/security/SimpleAuthorizingInterceptor.java>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Posted by Daniel Kulp <dk...@apache.org>.
My main "concern" with the implementation of this is that it's done as a
direct subclass of the WSS4JInInterceptor and thus not really usable by the
policy based endpoints as those interceptors subclass WSS4JInInterceptor as
well.
I think the better approach may be to add a flag to wss4j (I can help commit
changes there if needed) to have it not do any UserName token processing at
all. (aside: this may be doable without changes to wss4j by registering our
own "do nothing processor") Then, have another interceptor that runs after
the WSS4JInInterceptor that would actually handle the UsernameToken and verify
anything it needs and such.
To be honest, I WANT to do this for the Policy based stuff anyway. There is
currently some duplicated code between the PolicyBasedWSS4JIinInterceptor and
the new UsernameTokenInterceptor that could be eliminated by having the
PolicyBasedWSS4JIinInterceptor not do UsernameTokens at all and delegate that
completely to the UsernameTokenInterceptor.
Basically, it would be good if the WSS4JIn* stuff just handled the
encryption/signature stuff and then let the authorization validations stuff to
later interceptors. That would include things like key validation checking
and stuff as well. Probably SAML token validation as well.
Dan
On Thursday 08 April 2010 12:09:24 pm Sergey Beryozkin wrote:
> Hi David
>
> thanks for the comments...
>
> On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org> wrote:
> > Sergey,
> >
> > I think this type of functionality would be very useful to a number of
> > folks. I have built two similar capabilities for clients very recently
> > using CXF and Spring Security. Based on the code provided below, I have
> > several points that I would like to see addressed in a solution.
> >
> > 1) Architecture to support more than just UsernameTokens. I have worked
> > with systems that need to authenticate a user using UsernameTokens,
> > BinarySecurityTokens, SAML Assertions, and a combination of more than one
> > of
> > these at a time.
>
> Supporting UsernameTokens is the initial requirement. At the moment I do
> not even know how BinarySecurityTokens or SAML Assertions are
> processed/validated in CXF or WSS4J.
>
> > For the most part, WSS4J simply validates the structural
> > details of security. That is, signature validity, trust chaining of
> > digital
> > certificates, etc. As Glen pointed out with his reference to
> > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes performs
> > its
> > own password checking (authentication). Unfortunately, WSS4J doesn't
> > provide hooks for authenticating other forms of credentials that I have
> > listed above (I don't consider trust to be equivalent to authentication).
> > It would be best if the authentication interface supported multiple
> > credential types and allowed for authentication to be performed in a
> > single location in the same manner every time (not sometimes in the
> > WSS4J callback and sometimes in another interceptor for non-UT based
> > credentials).
>
> Makes sense. Assuming it is WSS4J which validates (the structure of)
> BinarySecurityTokens then AbstractWSS4JSecurityContextProvidingInterceptor
> can also implement a processor for BinarySecurityTokens and delegate to
> subclass to authenticate and setup a subject. Some extra methods will need
> to be added, to be optionally overridden.
>
> If it is not only WSS4J which is involved then perhaps another option is to
> store (from WSS4J callback handler, etc) relevant details such username
> token details, etc to be acted upon by other interceptors.
>
> > That
> > last bit there means disabling WSS4J's password authentication since it
> > gets
> > in the way of doing it later in our own interceptor.
>
> AbstractWSS4JSecurityContextProvidingInterceptor does it now by
> implementing a simplified UsernameTokenProcessor
>
> > 2) Allow for end-user flexibility in choosing the credentials they want
> > to authenticate. For instance, each user is going to have their own
> > security profiles and authentication requirements. For instance, a
> > message contains a UT for a portal user and a digital signature from the
> > portal (I know using
> > a SAML Assertion would be better here, but people still do it this way).
> > Each organization will have different requirements as to which
> > credentials get authenticated and what needs to end up in the security
> > context.
>
> I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
> should be able to do it, for username tokens and other tokens later on.
>
> > 3) Decouple the authentication interface from WSS4J. What is passed in
> > needs to be abstracted enough that it can work with other WS-Security
> > libraries as well.
>
> the only WSS4J class which is leaked at the moment is WSSecurityException.
> Perhaps we can come up later on with a different more generic approach
> which does not depend on WSS4J at all. As Dan indicated, in some cases
> WSS4JInInterceptor is not even used, so that case will need to be
> addressed. Experimenting wuth binary tokens might help with identifying
> another solution.
>
> > 4) It would be nice to be able to perform authorization using something
> > like
> > Spring Security at the service operation level. With a POJO or JAX-WS
> > based
> > service, one can just use Spring Security's method interceptor to provide
> > such security; however, in situations where one only has a WSDL based
> > service or a provider style service, a method interceptor can't be used.
> >
> > It
> >
> > would be nice to provide a hook into Spring Security to allow end-users
> > to specify role based authorization policy based on a combination of
> > interface,
> > instance, and operation names. It seems like your
> > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
> > looking in this direction, but I think it would be best if we can stand
> > on the shoulders of the Spring Security giant as much as possible so
> > that we can take advantage of their rich authorization manager, voter,
> > XML
> > configuration
> > capabilities.
>
> Not sure what to say here yet. But I think non-Spring users should be taken
> care of too. Or when simpler cases are dealt with then perhaps there's no
> need to bring in Spring security. Perhaps the utility authorization
> interceptors should just not be used when Spring Security is preferred ?
>
> > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The CXF-BC
> > currently has a limited capability to select the credentials to
> > authenticate
> > and would benefit from 1 and 2 above. The CXF-BC ultimately delegates
> > authentication to the JBI container through a ServiceMix components
> > authentication service abstraction of JAAS. Whatever solution we have
> > for 1
> > and 2 would help out the component if the ServiceMix authentication
> > service abstraction could be wired up in lieu of whatever we provide out
> > of the box.
>
> I'm not planning to contribute to ServiceMix. I agree though that an ideal
> solution will meet multiple requirements
>
> thanks, Sergey
>
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> > Sent: Wednesday, April 07, 2010 10:11 AM
> > To: dev@cxf.apache.org
> > Subject: Using WS-Security UsernameToken to authenticate users and
> > populate SecurityContexts
> >
> > Hi
> >
> > I've been looking recently at extending the CXF WS-Security component
> > such that a current UsernameToken could be used by custom interceptors
> > to authenticate a user with the external security systems and, if
> > possible, provide enough information for CXF to populate a
> > SecurityContext [1] to be used later on for
> > authorization decisions.
> >
> > Here is the approach I've taken so far.
> > A custom interceptor extends
> > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method
> > it overrides is
> >
> > abstract Subject createSubject(String name, String password, boolean
> > isDigest,
> >
> > String nonce,
> > String created) throws
> >
> > WSSecurityException;
> >
> >
> > For example, see [3].
> >
> > The idea here is that a custom interceptor interfaces whichever way it
> > needs
> > to with the external system and populates a Subject following this simple
> > rule : first Subject principal is the current user (identified by a
> > 'name' argument), followed by one or more Groups this user is a member
> > of. AbstractWSS4JSecurityContextProvidingInterceptor will use this
> > Subject to provide a functional SecurityContext instance.
> >
> > This is the first part, next is how to utilize a SecurityContext and get
> > the
> > expected roles associated one way or the other with a current method to
> > be invoked. There's a number of usual options available here, perhaps
> > even SpringSecurity can be used now that SecurityContext is available,
> > or application code or other custom CXF interceptor can check the known
> > roles against SecurityContext.
> >
> > I've also added AbstractAuthorizingInInterceptor interceptor which custom
> > interceptors can override and return a list of expected roles given a
> > (service) Method to be invoked upon, AbstractAuthorizingInInterceptor
> > will then ask available SecurityContext to match the roles; one concrete
> > implementation is SimpleAuthorizingInterceptor[5], it can be injected
> > with a
> > method specific or class (applying to all methods) roles. Another
> > implementation which I will likely add later on will be injected with a
> > name
> > of annotation such as RolesAlloved and it will introspect a method and
> > its class.
> >
> > Note that I haven't looked into the case when a policy runtimes adds the
> > interceptors yet (as opposed to interceptors being configured form
> > Spring/programmatically). I think an optional contextual property will
> > need to be setup in such cases for users be able to indicate that say an
> > interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
> > etc.
> >
> > I'm going to validate this approach with JBoss CXF. If you have any
> > comments
> > then please let me know.
> >
> > I think we may have a simpler alternative eventually to the way
> > authorization decisions are made. [1]-[3] is specific to ws-security, but
> > [4]-[5] is not
> >
> > cheers, Sergey
> >
> > [1] https://issues.apache.org/jira/browse/CXF-2754
> > [2]
> >
> > http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/or
> > g/a
> >
> > pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingIntercep
> > tor<http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/jav
> > a/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidi
> > ngInterceptor> .java
> > [3]
> >
> > http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/or
> > g/a
> > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http:/
> > /svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0A
> > pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java> [4]
> >
> > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> > e/c
> > xf/interceptor/security/AbstractAuthorizingInInterceptor.java<http://svn
> > .apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/i
> > nterceptor/security/AbstractAuthorizingInInterceptor.java> [5]
> >
> > http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apach
> > e/c
> > xf/interceptor/security/SimpleAuthorizingInterceptor.java<http://svn.apa
> > che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/inter
> > ceptor/security/SimpleAuthorizingInterceptor.java>
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
On Wed, Apr 14, 2010 at 2:46 PM, David Valeri <dv...@apache.org> wrote:
> Sergey,
>
> I've seen some commits go by relating to this work. Would it be worth
> another look at this time or should I wait a little longer before looking
> at
> it again?
>
>
Comments are welcome at any moment of time. Just FYI, all the latest merges
have been to do with simplifying/makeing it easy
to write concrete implementations of
AbstractWSS4JSecurityContextProvidingInterceptor and making them work well
in conjunction with SimpleAuthorizingInterceptor. As far as WSS4J is
concerned, I've been still targeting the initial case where users start
configuring their endpoints from Spring. Policy-first one needs to be
investigated next.
> I also have one additional consideration that I forgot to mention earlier.
> The case where anonymous authentication is OK. Last I checked
> WSS4jInInterceptor would not allow a no security condition if one or more
> actions are set, even if ignore actions is set to true. In some cases, no
> security is a valid "profile". The WSS4J interceptor still needs all
> possible actions configured such that it can handle any of the valid
> profiles that a client throws at it. Whatever approach you take should not
> preclude this scenario.
What do you mean by 'no security condition' - the absence of the
UsernameToken in the current request (lets just ignore other alternative
tokens for a moment) ? Perhaps, with the current WSS4J which strictly
requires a UsernameToken processor, we can rely on the fact that
AbstractWSS4JSecurityContextProvidingInterceptor implements a custom
UsernameToken processor, so it can be configured to allow for no
UsernameToken being in the current request and create a Subject with an
anonymous principal (again, the name of such principal can be configured),
similarly it could create a custom SecurityContext which will retirn true in
its isUserInRole for a role name like 'guest', etc
> Additional work may be required to allow the
> traditional and policy based WSS4J interceptors to support this scenario (I
> have written code to do this before), but the new code should be aware of
> this requirement in its initial design.
>
> If you are interested in some high level diagrams of how I have solved the
> above and previous mentioned issues in the past, let me know and I will put
> something together for you.
>
Perhaps you might want to create a CXF wiki page ?
thanks, Sergey
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Thursday, April 08, 2010 12:09 PM
> To: dev@cxf.apache.org
> Subject: Re: Using WS-Security UsernameToken to authenticate users and
> populate SecurityContexts
>
> Hi David
>
> thanks for the comments...
>
> On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org> wrote:
>
> > Sergey,
> >
> > I think this type of functionality would be very useful to a number of
> > folks. I have built two similar capabilities for clients very recently
> > using CXF and Spring Security. Based on the code provided below, I have
> > several points that I would like to see addressed in a solution.
> >
> > 1) Architecture to support more than just UsernameTokens. I have worked
> > with systems that need to authenticate a user using UsernameTokens,
> > BinarySecurityTokens, SAML Assertions, and a combination of more than one
> > of
> > these at a time.
>
>
> Supporting UsernameTokens is the initial requirement. At the moment I do
> not
> even know how BinarySecurityTokens or SAML Assertions are
> processed/validated in CXF or WSS4J.
>
>
> > For the most part, WSS4J simply validates the structural
> > details of security. That is, signature validity, trust chaining of
> > digital
> > certificates, etc. As Glen pointed out with his reference to
> > https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes performs
> > its
> > own password checking (authentication). Unfortunately, WSS4J doesn't
> > provide hooks for authenticating other forms of credentials that I have
> > listed above (I don't consider trust to be equivalent to authentication).
> > It would be best if the authentication interface supported multiple
> > credential types and allowed for authentication to be performed in a
> single
> > location in the same manner every time (not sometimes in the WSS4J
> callback
> > and sometimes in another interceptor for non-UT based credentials).
>
>
> Makes sense. Assuming it is WSS4J which validates (the structure of)
> BinarySecurityTokens then AbstractWSS4JSecurityContextProvidingInterceptor
> can also implement a processor for BinarySecurityTokens and delegate to
> subclass to authenticate and setup a subject. Some extra methods will need
> to be added, to be optionally overridden.
>
> If it is not only WSS4J which is involved then perhaps another option is to
> store (from WSS4J callback handler, etc) relevant details such username
> token details, etc to be acted upon by other interceptors.
>
>
> > That
> > last bit there means disabling WSS4J's password authentication since it
> > gets
> > in the way of doing it later in our own interceptor.
> >
>
> AbstractWSS4JSecurityContextProvidingInterceptor does it now by
> implementing
> a simplified UsernameTokenProcessor
>
>
> >
> > 2) Allow for end-user flexibility in choosing the credentials they want
> to
> > authenticate. For instance, each user is going to have their own
> security
> > profiles and authentication requirements. For instance, a message
> contains
> > a UT for a portal user and a digital signature from the portal (I know
> > using
> > a SAML Assertion would be better here, but people still do it this way).
> > Each organization will have different requirements as to which
> credentials
> > get authenticated and what needs to end up in the security context.
> >
>
> I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
> should
> be able to do it, for username tokens and other tokens later on.
>
>
> >
> > 3) Decouple the authentication interface from WSS4J. What is passed in
> > needs to be abstracted enough that it can work with other WS-Security
> > libraries as well.
> >
> >
> the only WSS4J class which is leaked at the moment is WSSecurityException.
> Perhaps we can come up later on with a different more generic approach
> which
> does not depend on WSS4J at all. As Dan indicated, in some cases
> WSS4JInInterceptor is not even used, so that case will need to be
> addressed.
> Experimenting wuth binary tokens might help with identifying another
> solution.
>
>
> > 4) It would be nice to be able to perform authorization using something
> > like
> > Spring Security at the service operation level. With a POJO or JAX-WS
> > based
> > service, one can just use Spring Security's method interceptor to provide
> > such security; however, in situations where one only has a WSDL based
> > service or a provider style service, a method interceptor can't be used.
> > It
> > would be nice to provide a hook into Spring Security to allow end-users
> to
> > specify role based authorization policy based on a combination of
> > interface,
> > instance, and operation names. It seems like your
> > AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
> looking
> > in this direction, but I think it would be best if we can stand on the
> > shoulders of the Spring Security giant as much as possible so that we can
> > take advantage of their rich authorization manager, voter, XML
> > configuration
> > capabilities.
> >
> >
> Not sure what to say here yet. But I think non-Spring users should be taken
> care of too. Or when simpler cases are dealt with then perhaps there's no
> need to bring in Spring security. Perhaps the utility authorization
> interceptors should just not be used when Spring Security is preferred ?
>
>
> > 5) Try not to leave the ServiceMix CXF-BC out in the cold. The CXF-BC
> > currently has a limited capability to select the credentials to
> > authenticate
> > and would benefit from 1 and 2 above. The CXF-BC ultimately delegates
> > authentication to the JBI container through a ServiceMix components
> > authentication service abstraction of JAAS. Whatever solution we have
> for
> > 1
> > and 2 would help out the component if the ServiceMix authentication
> service
> > abstraction could be wired up in lieu of whatever we provide out of the
> > box.
> >
> >
> I'm not planning to contribute to ServiceMix. I agree though that an ideal
> solution will meet multiple requirements
>
> thanks, Sergey
>
>
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> > Sent: Wednesday, April 07, 2010 10:11 AM
> > To: dev@cxf.apache.org
> > Subject: Using WS-Security UsernameToken to authenticate users and
> populate
> > SecurityContexts
> >
> > Hi
> >
> > I've been looking recently at extending the CXF WS-Security component
> such
> > that a current UsernameToken could be used by custom interceptors
> > to authenticate a user with the external security systems and, if
> possible,
> > provide enough information for CXF to populate a SecurityContext [1] to
> be
> > used later on for
> > authorization decisions.
> >
> > Here is the approach I've taken so far.
> > A custom interceptor extends
> > AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method
> it
> > overrides is
> >
> > abstract Subject createSubject(String name, String password, boolean
> > isDigest,
> >
> > String nonce,
> > String created) throws
> > WSSecurityException;
> >
> >
> > For example, see [3].
> >
> > The idea here is that a custom interceptor interfaces whichever way it
> > needs
> > to with the external system and populates a Subject following this simple
> > rule : first Subject principal is the current user (identified by a
> 'name'
> > argument), followed by one or more Groups this user is a member of.
> > AbstractWSS4JSecurityContextProvidingInterceptor will use this Subject to
> > provide a functional SecurityContext instance.
> >
> > This is the first part, next is how to utilize a SecurityContext and get
> > the
> > expected roles associated one way or the other with a current method to
> be
> > invoked. There's a number of usual options available here, perhaps even
> > SpringSecurity can be used now that SecurityContext is available, or
> > application code or other custom CXF interceptor can check the known
> roles
> > against SecurityContext.
> >
> > I've also added AbstractAuthorizingInInterceptor interceptor which custom
> > interceptors can override and return a list of expected roles given a
> > (service) Method to be invoked upon, AbstractAuthorizingInInterceptor
> will
> > then ask available SecurityContext to match the roles; one concrete
> > implementation is SimpleAuthorizingInterceptor[5], it can be injected
> with
> > a
> > method specific or class (applying to all methods) roles. Another
> > implementation which I will likely add later on will be injected with a
> > name
> > of annotation such as RolesAlloved and it will introspect a method and
> its
> > class.
> >
> > Note that I haven't looked into the case when a policy runtimes adds the
> > interceptors yet (as opposed to interceptors being configured form
> > Spring/programmatically). I think an optional contextual property will
> need
> > to be setup in such cases for users be able to indicate that say an
> > interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
> > etc.
> >
> > I'm going to validate this approach with JBoss CXF. If you have any
> > comments
> > then please let me know.
> >
> > I think we may have a simpler alternative eventually to the way
> > authorization decisions are made. [1]-[3] is specific to ws-security, but
> > [4]-[5] is not
> >
> > cheers, Sergey
> >
> > [1] https://issues.apache.org/jira/browse/CXF-2754
> > [2]
> >
> >
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
> >
> >
>
> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor
> <
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/
>
> a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterce
> ptor>
> > .java
> > [3]
> >
> >
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a
> >
> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<
> http://svn
> .
> apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0Apache/c
> xf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
> > [4]
> >
> >
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c
> >
> xf/interceptor/security/AbstractAuthorizingInInterceptor.java<
> http://svn.apa
>
> che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/intercep
> tor/security/AbstractAuthorizingInInterceptor.java>
> > [5]
> >
> >
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c
> >
> xf/interceptor/security/SimpleAuthorizingInterceptor.java<
> http://svn.apache.
>
> org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/interceptor/
> security/SimpleAuthorizingInterceptor.java>
> >
> >
>
>
RE: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Posted by David Valeri <dv...@apache.org>.
Sergey,
I've seen some commits go by relating to this work. Would it be worth
another look at this time or should I wait a little longer before looking at
it again?
I also have one additional consideration that I forgot to mention earlier.
The case where anonymous authentication is OK. Last I checked
WSS4jInInterceptor would not allow a no security condition if one or more
actions are set, even if ignore actions is set to true. In some cases, no
security is a valid "profile". The WSS4J interceptor still needs all
possible actions configured such that it can handle any of the valid
profiles that a client throws at it. Whatever approach you take should not
preclude this scenario. Additional work may be required to allow the
traditional and policy based WSS4J interceptors to support this scenario (I
have written code to do this before), but the new code should be aware of
this requirement in its initial design.
If you are interested in some high level diagrams of how I have solved the
above and previous mentioned issues in the past, let me know and I will put
something together for you.
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Thursday, April 08, 2010 12:09 PM
To: dev@cxf.apache.org
Subject: Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Hi David
thanks for the comments...
On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org> wrote:
> Sergey,
>
> I think this type of functionality would be very useful to a number of
> folks. I have built two similar capabilities for clients very recently
> using CXF and Spring Security. Based on the code provided below, I have
> several points that I would like to see addressed in a solution.
>
> 1) Architecture to support more than just UsernameTokens. I have worked
> with systems that need to authenticate a user using UsernameTokens,
> BinarySecurityTokens, SAML Assertions, and a combination of more than one
> of
> these at a time.
Supporting UsernameTokens is the initial requirement. At the moment I do not
even know how BinarySecurityTokens or SAML Assertions are
processed/validated in CXF or WSS4J.
> For the most part, WSS4J simply validates the structural
> details of security. That is, signature validity, trust chaining of
> digital
> certificates, etc. As Glen pointed out with his reference to
> https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes performs
> its
> own password checking (authentication). Unfortunately, WSS4J doesn't
> provide hooks for authenticating other forms of credentials that I have
> listed above (I don't consider trust to be equivalent to authentication).
> It would be best if the authentication interface supported multiple
> credential types and allowed for authentication to be performed in a
single
> location in the same manner every time (not sometimes in the WSS4J
callback
> and sometimes in another interceptor for non-UT based credentials).
Makes sense. Assuming it is WSS4J which validates (the structure of)
BinarySecurityTokens then AbstractWSS4JSecurityContextProvidingInterceptor
can also implement a processor for BinarySecurityTokens and delegate to
subclass to authenticate and setup a subject. Some extra methods will need
to be added, to be optionally overridden.
If it is not only WSS4J which is involved then perhaps another option is to
store (from WSS4J callback handler, etc) relevant details such username
token details, etc to be acted upon by other interceptors.
> That
> last bit there means disabling WSS4J's password authentication since it
> gets
> in the way of doing it later in our own interceptor.
>
AbstractWSS4JSecurityContextProvidingInterceptor does it now by implementing
a simplified UsernameTokenProcessor
>
> 2) Allow for end-user flexibility in choosing the credentials they want to
> authenticate. For instance, each user is going to have their own security
> profiles and authentication requirements. For instance, a message
contains
> a UT for a portal user and a digital signature from the portal (I know
> using
> a SAML Assertion would be better here, but people still do it this way).
> Each organization will have different requirements as to which credentials
> get authenticated and what needs to end up in the security context.
>
I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses should
be able to do it, for username tokens and other tokens later on.
>
> 3) Decouple the authentication interface from WSS4J. What is passed in
> needs to be abstracted enough that it can work with other WS-Security
> libraries as well.
>
>
the only WSS4J class which is leaked at the moment is WSSecurityException.
Perhaps we can come up later on with a different more generic approach which
does not depend on WSS4J at all. As Dan indicated, in some cases
WSS4JInInterceptor is not even used, so that case will need to be addressed.
Experimenting wuth binary tokens might help with identifying another
solution.
> 4) It would be nice to be able to perform authorization using something
> like
> Spring Security at the service operation level. With a POJO or JAX-WS
> based
> service, one can just use Spring Security's method interceptor to provide
> such security; however, in situations where one only has a WSDL based
> service or a provider style service, a method interceptor can't be used.
> It
> would be nice to provide a hook into Spring Security to allow end-users to
> specify role based authorization policy based on a combination of
> interface,
> instance, and operation names. It seems like your
> AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are
looking
> in this direction, but I think it would be best if we can stand on the
> shoulders of the Spring Security giant as much as possible so that we can
> take advantage of their rich authorization manager, voter, XML
> configuration
> capabilities.
>
>
Not sure what to say here yet. But I think non-Spring users should be taken
care of too. Or when simpler cases are dealt with then perhaps there's no
need to bring in Spring security. Perhaps the utility authorization
interceptors should just not be used when Spring Security is preferred ?
> 5) Try not to leave the ServiceMix CXF-BC out in the cold. The CXF-BC
> currently has a limited capability to select the credentials to
> authenticate
> and would benefit from 1 and 2 above. The CXF-BC ultimately delegates
> authentication to the JBI container through a ServiceMix components
> authentication service abstraction of JAAS. Whatever solution we have for
> 1
> and 2 would help out the component if the ServiceMix authentication
service
> abstraction could be wired up in lieu of whatever we provide out of the
> box.
>
>
I'm not planning to contribute to ServiceMix. I agree though that an ideal
solution will meet multiple requirements
thanks, Sergey
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Wednesday, April 07, 2010 10:11 AM
> To: dev@cxf.apache.org
> Subject: Using WS-Security UsernameToken to authenticate users and
populate
> SecurityContexts
>
> Hi
>
> I've been looking recently at extending the CXF WS-Security component such
> that a current UsernameToken could be used by custom interceptors
> to authenticate a user with the external security systems and, if
possible,
> provide enough information for CXF to populate a SecurityContext [1] to be
> used later on for
> authorization decisions.
>
> Here is the approach I've taken so far.
> A custom interceptor extends
> AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method
it
> overrides is
>
> abstract Subject createSubject(String name, String password, boolean
> isDigest,
>
> String nonce,
> String created) throws
> WSSecurityException;
>
>
> For example, see [3].
>
> The idea here is that a custom interceptor interfaces whichever way it
> needs
> to with the external system and populates a Subject following this simple
> rule : first Subject principal is the current user (identified by a 'name'
> argument), followed by one or more Groups this user is a member of.
> AbstractWSS4JSecurityContextProvidingInterceptor will use this Subject to
> provide a functional SecurityContext instance.
>
> This is the first part, next is how to utilize a SecurityContext and get
> the
> expected roles associated one way or the other with a current method to be
> invoked. There's a number of usual options available here, perhaps even
> SpringSecurity can be used now that SecurityContext is available, or
> application code or other custom CXF interceptor can check the known roles
> against SecurityContext.
>
> I've also added AbstractAuthorizingInInterceptor interceptor which custom
> interceptors can override and return a list of expected roles given a
> (service) Method to be invoked upon, AbstractAuthorizingInInterceptor will
> then ask available SecurityContext to match the roles; one concrete
> implementation is SimpleAuthorizingInterceptor[5], it can be injected with
> a
> method specific or class (applying to all methods) roles. Another
> implementation which I will likely add later on will be injected with a
> name
> of annotation such as RolesAlloved and it will introspect a method and its
> class.
>
> Note that I haven't looked into the case when a policy runtimes adds the
> interceptors yet (as opposed to interceptors being configured form
> Spring/programmatically). I think an optional contextual property will
need
> to be setup in such cases for users be able to indicate that say an
> interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
> etc.
>
> I'm going to validate this approach with JBoss CXF. If you have any
> comments
> then please let me know.
>
> I think we may have a simpler alternative eventually to the way
> authorization decisions are made. [1]-[3] is specific to ws-security, but
> [4]-[5] is not
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/CXF-2754
> [2]
>
>
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
>
>
pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor
<http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/
a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterce
ptor>
> .java
> [3]
>
>
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a
>
pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http://svn
.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0Apache/c
xf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
> [4]
>
>
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c
>
xf/interceptor/security/AbstractAuthorizingInInterceptor.java<http://svn.apa
che.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/intercep
tor/security/AbstractAuthorizingInInterceptor.java>
> [5]
>
>
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c
>
xf/interceptor/security/SimpleAuthorizingInterceptor.java<http://svn.apache.
org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/interceptor/
security/SimpleAuthorizingInterceptor.java>
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
thanks for the comments...
On Wed, Apr 7, 2010 at 9:41 PM, David Valeri <dv...@apache.org> wrote:
> Sergey,
>
> I think this type of functionality would be very useful to a number of
> folks. I have built two similar capabilities for clients very recently
> using CXF and Spring Security. Based on the code provided below, I have
> several points that I would like to see addressed in a solution.
>
> 1) Architecture to support more than just UsernameTokens. I have worked
> with systems that need to authenticate a user using UsernameTokens,
> BinarySecurityTokens, SAML Assertions, and a combination of more than one
> of
> these at a time.
Supporting UsernameTokens is the initial requirement. At the moment I do not
even know how BinarySecurityTokens or SAML Assertions are
processed/validated in CXF or WSS4J.
> For the most part, WSS4J simply validates the structural
> details of security. That is, signature validity, trust chaining of
> digital
> certificates, etc. As Glen pointed out with his reference to
> https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes performs
> its
> own password checking (authentication). Unfortunately, WSS4J doesn't
> provide hooks for authenticating other forms of credentials that I have
> listed above (I don't consider trust to be equivalent to authentication).
> It would be best if the authentication interface supported multiple
> credential types and allowed for authentication to be performed in a single
> location in the same manner every time (not sometimes in the WSS4J callback
> and sometimes in another interceptor for non-UT based credentials).
Makes sense. Assuming it is WSS4J which validates (the structure of)
BinarySecurityTokens then AbstractWSS4JSecurityContextProvidingInterceptor
can also implement a processor for BinarySecurityTokens and delegate to
subclass to authenticate and setup a subject. Some extra methods will need
to be added, to be optionally overridden.
If it is not only WSS4J which is involved then perhaps another option is to
store (from WSS4J callback handler, etc) relevant details such username
token details, etc to be acted upon by other interceptors.
> That
> last bit there means disabling WSS4J's password authentication since it
> gets
> in the way of doing it later in our own interceptor.
>
AbstractWSS4JSecurityContextProvidingInterceptor does it now by implementing
a simplified UsernameTokenProcessor
>
> 2) Allow for end-user flexibility in choosing the credentials they want to
> authenticate. For instance, each user is going to have their own security
> profiles and authentication requirements. For instance, a message contains
> a UT for a portal user and a digital signature from the portal (I know
> using
> a SAML Assertion would be better here, but people still do it this way).
> Each organization will have different requirements as to which credentials
> get authenticated and what needs to end up in the security context.
>
I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses should
be able to do it, for username tokens and other tokens later on.
>
> 3) Decouple the authentication interface from WSS4J. What is passed in
> needs to be abstracted enough that it can work with other WS-Security
> libraries as well.
>
>
the only WSS4J class which is leaked at the moment is WSSecurityException.
Perhaps we can come up later on with a different more generic approach which
does not depend on WSS4J at all. As Dan indicated, in some cases
WSS4JInInterceptor is not even used, so that case will need to be addressed.
Experimenting wuth binary tokens might help with identifying another
solution.
> 4) It would be nice to be able to perform authorization using something
> like
> Spring Security at the service operation level. With a POJO or JAX-WS
> based
> service, one can just use Spring Security's method interceptor to provide
> such security; however, in situations where one only has a WSDL based
> service or a provider style service, a method interceptor can't be used.
> It
> would be nice to provide a hook into Spring Security to allow end-users to
> specify role based authorization policy based on a combination of
> interface,
> instance, and operation names. It seems like your
> AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are looking
> in this direction, but I think it would be best if we can stand on the
> shoulders of the Spring Security giant as much as possible so that we can
> take advantage of their rich authorization manager, voter, XML
> configuration
> capabilities.
>
>
Not sure what to say here yet. But I think non-Spring users should be taken
care of too. Or when simpler cases are dealt with then perhaps there's no
need to bring in Spring security. Perhaps the utility authorization
interceptors should just not be used when Spring Security is preferred ?
> 5) Try not to leave the ServiceMix CXF-BC out in the cold. The CXF-BC
> currently has a limited capability to select the credentials to
> authenticate
> and would benefit from 1 and 2 above. The CXF-BC ultimately delegates
> authentication to the JBI container through a ServiceMix components
> authentication service abstraction of JAAS. Whatever solution we have for
> 1
> and 2 would help out the component if the ServiceMix authentication service
> abstraction could be wired up in lieu of whatever we provide out of the
> box.
>
>
I'm not planning to contribute to ServiceMix. I agree though that an ideal
solution will meet multiple requirements
thanks, Sergey
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Wednesday, April 07, 2010 10:11 AM
> To: dev@cxf.apache.org
> Subject: Using WS-Security UsernameToken to authenticate users and populate
> SecurityContexts
>
> Hi
>
> I've been looking recently at extending the CXF WS-Security component such
> that a current UsernameToken could be used by custom interceptors
> to authenticate a user with the external security systems and, if possible,
> provide enough information for CXF to populate a SecurityContext [1] to be
> used later on for
> authorization decisions.
>
> Here is the approach I've taken so far.
> A custom interceptor extends
> AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method it
> overrides is
>
> abstract Subject createSubject(String name, String password, boolean
> isDigest,
>
> String nonce,
> String created) throws
> WSSecurityException;
>
>
> For example, see [3].
>
> The idea here is that a custom interceptor interfaces whichever way it
> needs
> to with the external system and populates a Subject following this simple
> rule : first Subject principal is the current user (identified by a 'name'
> argument), followed by one or more Groups this user is a member of.
> AbstractWSS4JSecurityContextProvidingInterceptor will use this Subject to
> provide a functional SecurityContext instance.
>
> This is the first part, next is how to utilize a SecurityContext and get
> the
> expected roles associated one way or the other with a current method to be
> invoked. There's a number of usual options available here, perhaps even
> SpringSecurity can be used now that SecurityContext is available, or
> application code or other custom CXF interceptor can check the known roles
> against SecurityContext.
>
> I've also added AbstractAuthorizingInInterceptor interceptor which custom
> interceptors can override and return a list of expected roles given a
> (service) Method to be invoked upon, AbstractAuthorizingInInterceptor will
> then ask available SecurityContext to match the roles; one concrete
> implementation is SimpleAuthorizingInterceptor[5], it can be injected with
> a
> method specific or class (applying to all methods) roles. Another
> implementation which I will likely add later on will be injected with a
> name
> of annotation such as RolesAlloved and it will introspect a method and its
> class.
>
> Note that I haven't looked into the case when a policy runtimes adds the
> interceptors yet (as opposed to interceptors being configured form
> Spring/programmatically). I think an optional contextual property will need
> to be setup in such cases for users be able to indicate that say an
> interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
> etc.
>
> I'm going to validate this approach with JBoss CXF. If you have any
> comments
> then please let me know.
>
> I think we may have a simpler alternative eventually to the way
> authorization decisions are made. [1]-[3] is specific to ws-security, but
> [4]-[5] is not
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/CXF-2754
> [2]
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
>
> pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor<http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a%0Apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor>
> .java
> [3]
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a
> pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java<http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a%0Apache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java>
> [4]
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c
> xf/interceptor/security/AbstractAuthorizingInInterceptor.java<http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/interceptor/security/AbstractAuthorizingInInterceptor.java>
> [5]
>
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c
> xf/interceptor/security/SimpleAuthorizingInterceptor.java<http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c%0Axf/interceptor/security/SimpleAuthorizingInterceptor.java>
>
>
RE: Using WS-Security UsernameToken to authenticate users and populate SecurityContexts
Posted by David Valeri <dv...@apache.org>.
Sergey,
I think this type of functionality would be very useful to a number of
folks. I have built two similar capabilities for clients very recently
using CXF and Spring Security. Based on the code provided below, I have
several points that I would like to see addressed in a solution.
1) Architecture to support more than just UsernameTokens. I have worked
with systems that need to authenticate a user using UsernameTokens,
BinarySecurityTokens, SAML Assertions, and a combination of more than one of
these at a time. For the most part, WSS4J simply validates the structural
details of security. That is, signature validity, trust chaining of digital
certificates, etc. As Glen pointed out with his reference to
https://issues.apache.org/jira/browse/WSS-183, WSS4J sometimes performs its
own password checking (authentication). Unfortunately, WSS4J doesn't
provide hooks for authenticating other forms of credentials that I have
listed above (I don't consider trust to be equivalent to authentication).
It would be best if the authentication interface supported multiple
credential types and allowed for authentication to be performed in a single
location in the same manner every time (not sometimes in the WSS4J callback
and sometimes in another interceptor for non-UT based credentials). That
last bit there means disabling WSS4J's password authentication since it gets
in the way of doing it later in our own interceptor.
2) Allow for end-user flexibility in choosing the credentials they want to
authenticate. For instance, each user is going to have their own security
profiles and authentication requirements. For instance, a message contains
a UT for a portal user and a digital signature from the portal (I know using
a SAML Assertion would be better here, but people still do it this way).
Each organization will have different requirements as to which credentials
get authenticated and what needs to end up in the security context.
3) Decouple the authentication interface from WSS4J. What is passed in
needs to be abstracted enough that it can work with other WS-Security
libraries as well.
4) It would be nice to be able to perform authorization using something like
Spring Security at the service operation level. With a POJO or JAX-WS based
service, one can just use Spring Security's method interceptor to provide
such security; however, in situations where one only has a WSDL based
service or a provider style service, a method interceptor can't be used. It
would be nice to provide a hook into Spring Security to allow end-users to
specify role based authorization policy based on a combination of interface,
instance, and operation names. It seems like your
AbstractAuthorizingInterceptor and SimpleAuthorizingInterceptor are looking
in this direction, but I think it would be best if we can stand on the
shoulders of the Spring Security giant as much as possible so that we can
take advantage of their rich authorization manager, voter, XML configuration
capabilities.
5) Try not to leave the ServiceMix CXF-BC out in the cold. The CXF-BC
currently has a limited capability to select the credentials to authenticate
and would benefit from 1 and 2 above. The CXF-BC ultimately delegates
authentication to the JBI container through a ServiceMix components
authentication service abstraction of JAAS. Whatever solution we have for 1
and 2 would help out the component if the ServiceMix authentication service
abstraction could be wired up in lieu of whatever we provide out of the box.
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Wednesday, April 07, 2010 10:11 AM
To: dev@cxf.apache.org
Subject: Using WS-Security UsernameToken to authenticate users and populate
SecurityContexts
Hi
I've been looking recently at extending the CXF WS-Security component such
that a current UsernameToken could be used by custom interceptors
to authenticate a user with the external security systems and, if possible,
provide enough information for CXF to populate a SecurityContext [1] to be
used later on for
authorization decisions.
Here is the approach I've taken so far.
A custom interceptor extends
AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method it
overrides is
abstract Subject createSubject(String name, String password, boolean
isDigest,
String nonce,
String created) throws
WSSecurityException;
For example, see [3].
The idea here is that a custom interceptor interfaces whichever way it needs
to with the external system and populates a Subject following this simple
rule : first Subject principal is the current user (identified by a 'name'
argument), followed by one or more Groups this user is a member of.
AbstractWSS4JSecurityContextProvidingInterceptor will use this Subject to
provide a functional SecurityContext instance.
This is the first part, next is how to utilize a SecurityContext and get the
expected roles associated one way or the other with a current method to be
invoked. There's a number of usual options available here, perhaps even
SpringSecurity can be used now that SecurityContext is available, or
application code or other custom CXF interceptor can check the known roles
against SecurityContext.
I've also added AbstractAuthorizingInInterceptor interceptor which custom
interceptors can override and return a list of expected roles given a
(service) Method to be invoked upon, AbstractAuthorizingInInterceptor will
then ask available SecurityContext to match the roles; one concrete
implementation is SimpleAuthorizingInterceptor[5], it can be injected with a
method specific or class (applying to all methods) roles. Another
implementation which I will likely add later on will be injected with a name
of annotation such as RolesAlloved and it will introspect a method and its
class.
Note that I haven't looked into the case when a policy runtimes adds the
interceptors yet (as opposed to interceptors being configured form
Spring/programmatically). I think an optional contextual property will need
to be setup in such cases for users be able to indicate that say an
interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
etc.
I'm going to validate this approach with JBoss CXF. If you have any comments
then please let me know.
I think we may have a simpler alternative eventually to the way
authorization decisions are made. [1]-[3] is specific to ws-security, but
[4]-[5] is not
cheers, Sergey
[1] https://issues.apache.org/jira/browse/CXF-2754
[2]
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/a
pache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor
.java
[3]
http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/a
pache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java
[4]
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c
xf/interceptor/security/AbstractAuthorizingInInterceptor.java
[5]
http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/c
xf/interceptor/security/SimpleAuthorizingInterceptor.java
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
typo, missed 'not'
"I'm sorry but this does *not* sounds convincing."
On Wed, Apr 7, 2010 at 5:22 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>>
>> Sergey, be careful with your first reason--that of using the
>> CallbackHandlers
>> to *return* passwords, that's an old erroneous design apparently since
>> fixed
>> in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
>> necessarily be used as a reason for doing what you're doing--that process
>> should be taken out of CXF instead when it upgrades to the new WSS4J.
>>
>
> I'm sorry but this does sounds convincing. You're kind of indicating that
> what is proposed
> is not good enough ? But you have not said anything about the
> authorization. WSS4J is restricting with respects to digests at thje moment
> but as I said, we're after the authorization here
>
>
>>
>> Actually, I think Metro does what you want--allows the option for
>> container-managed authentication *without* the callbackhandler
>> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
>> ).
>> If you can repeat the same with CXF, great!
>>
>
> I really don't follow why you refer to Metro, what is to do with the use of
> CXF ?
>
> Sergey
>
>
>>
>> Glen
>>
>>
>> Sergey Beryozkin-5 wrote:
>> >
>> > There are few problems with depending on CallbackHandlers only :
>> >
>> > - when passwords have been digested, WSS4JInterceptor requires a clear
>> > text
>> > password back to verify a digest which is not realistic in cases where
>> an
>> > external system can authenticate a user with the digest password but
>> have
>> > no
>> > way of returning an actual password for this CallbackHandler to give it
>> to
>> > WSS4JInterceptor
>> > - authentication is only part of the story, what is really important is
>> > that
>> > the authorization can be done further down the line. I don't think
>> trying
>> > to
>> > do the authorization from the CallbackHandler is a good approach - we
>> > don't
>> > even know the method name to be invoked upon
>> >
>> > Now, perhaps one can even authenticate and authorize from a callback
>> > handler
>> > by somehow getting to the current Message, figuring out the method name,
>> > etc. But IMHO the proposed approach is cleaner and it gives more options
>> > as
>> > to when an authorization should be done due to the fact we have a valid
>> > SecurityContext in scope
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Glen
On Wed, Apr 7, 2010 at 6:25 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>
> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
> >
> > Sergey, be careful with your first reason--that of using the
> > CallbackHandlers
> > to *return* passwords, that's an old erroneous design apparently since
> > fixed
> > in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
> > necessarily be used as a reason for doing what you're doing--that process
> > should be taken out of CXF instead when it upgrades to the new WSS4J.
> >
>
> >I'm sorry but this does [not] sounds convincing. You're kind of indicating
> that
> >what is proposed is not good enough ? But you have not said anything about
> the authorization.
> >WSS4J is restricting with respects to digests at thje moment but as I
> said,
> >we're after the authorization here.
>
> All I'm saying is that if you're using the argument of "CXF requires
> passwords to be supplied in the CallbackHandlers!" as a reason for doing
> what you're doing, that's not valid anymore because that problem is fixed
> with the new WSS4J.
I guess I was not specific enough, hope my follow-up response made things
clearer.
> I'm sure however there are plenty of other good reasons
> for doing what you're doing, it's just that that particular one should soon
> no longer be relevant. I was also mentioning this to you in case you were
> unaware of the problem and were thinking of a solution which involved the
> Callbackhandler continuing to serve its erroneous dual role
> (https://issues.apache.org/jira/browse/WSS-183,
> https://issues.apache.org/jira/browse/CXF-2150) of validating credentials
> for password text and providing credentials for password digest for some
> higher entity to validate.
>
I'm aware of this problem but it is an orthogonal one. Likewise not sure
what you mean by a dual role. In this case a callback handler only requires
a subclass to do the authentication.
>
>
> >
> > Actually, I think Metro does what you want--allows the option for
> > container-managed authentication *without* the callbackhandler
> > (
> http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
> > ).
> > If you can repeat the same with CXF, great!
> >
>
> > I really don't follow why you refer to Metro, what is to do with the use
> > of
> > CXF ?
>
> It was meant as a sanity check that whatever you are proposing is also
> being
> done by another web service stack. But I misunderstood what you were
> proposing, hence what I was saying above is not relevant. You're talking
> about authorization, not authentication. Never min
I'm talking about both authentication and authorization. I believe the
proposed solution makes it more easier to authorize, as I tried to clarify
in the other email.
cheers, Sergey
> d.
>
> Glen
>
> --
> View this message in context:
> http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28168187.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Glen Mazza <gl...@gmail.com>.
Glen,
On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
> Sergey, be careful with your first reason--that of using the
> CallbackHandlers
> to *return* passwords, that's an old erroneous design apparently since
> fixed
> in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
> necessarily be used as a reason for doing what you're doing--that process
> should be taken out of CXF instead when it upgrades to the new WSS4J.
>
>I'm sorry but this does [not] sounds convincing. You're kind of indicating
that
>what is proposed is not good enough ? But you have not said anything about
the authorization.
>WSS4J is restricting with respects to digests at thje moment but as I said,
>we're after the authorization here.
All I'm saying is that if you're using the argument of "CXF requires
passwords to be supplied in the CallbackHandlers!" as a reason for doing
what you're doing, that's not valid anymore because that problem is fixed
with the new WSS4J. I'm sure however there are plenty of other good reasons
for doing what you're doing, it's just that that particular one should soon
no longer be relevant. I was also mentioning this to you in case you were
unaware of the problem and were thinking of a solution which involved the
Callbackhandler continuing to serve its erroneous dual role
(https://issues.apache.org/jira/browse/WSS-183,
https://issues.apache.org/jira/browse/CXF-2150) of validating credentials
for password text and providing credentials for password digest for some
higher entity to validate.
>
> Actually, I think Metro does what you want--allows the option for
> container-managed authentication *without* the callbackhandler
> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
> ).
> If you can repeat the same with CXF, great!
>
> I really don't follow why you refer to Metro, what is to do with the use
> of
> CXF ?
It was meant as a sanity check that whatever you are proposing is also being
done by another web service stack. But I misunderstood what you were
proposing, hence what I was saying above is not relevant. You're talking
about authorization, not authentication. Never mind.
Glen
--
View this message in context: http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28168187.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Actually Glen, sorry for a speedy reply.
Here are some more clarifications.
Please have a look at the source of the
AbstractWSS4JSecurityContextProviding interceptor. In a nutshell, it is a
complex CallbackHandler which simply delegates the authentication to its
subclass overriding createSubject method, by passing to it a user name,
password(possibly digest), etc.
The subclass will authenticate but also return a populated Subject which
this CallbackHandler will store in the thread local storage to be later
retrieved, at a moment when WSS4JInterceptor creates SecurityContext. Note
that by default WSS4JInterceptor creates an incomplete SecurityContext which
always returns 'false' in its isUserInRole. By letting subclasses to
authenticate without implementing a CallbackHandler but also requiring them
to populate a Subject we ensure that an authentication has been done but
also make it possible to utilize a populated SecurityContext later on in the
chain.
Now, the above works for clear text passwords only at the moment (which
might've been encrypted if passed over HTTP). To avoid a current WSS4J
restriction with respect to digests, it also implements a simplified
UsernameTokenProcessor but ultimately it also delegates to a subclass.
Thanks for linking to that WSS4J jira. When CXF gets upgraded I can simplify
the implementation dramatically by removing a Processor impl.
hope it makes things clearer
cheers, Sergey
On Wed, Apr 7, 2010 at 5:22 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Glen,
>
>
> On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>>
>> Sergey, be careful with your first reason--that of using the
>> CallbackHandlers
>> to *return* passwords, that's an old erroneous design apparently since
>> fixed
>> in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
>> necessarily be used as a reason for doing what you're doing--that process
>> should be taken out of CXF instead when it upgrades to the new WSS4J.
>>
>
> I'm sorry but this does sounds convincing. You're kind of indicating that
> what is proposed
> is not good enough ? But you have not said anything about the
> authorization. WSS4J is restricting with respects to digests at thje moment
> but as I said, we're after the authorization here
>
>
>>
>> Actually, I think Metro does what you want--allows the option for
>> container-managed authentication *without* the callbackhandler
>> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
>> ).
>> If you can repeat the same with CXF, great!
>>
>
> I really don't follow why you refer to Metro, what is to do with the use of
> CXF ?
>
> Sergey
>
>
>>
>> Glen
>>
>>
>> Sergey Beryozkin-5 wrote:
>> >
>> > There are few problems with depending on CallbackHandlers only :
>> >
>> > - when passwords have been digested, WSS4JInterceptor requires a clear
>> > text
>> > password back to verify a digest which is not realistic in cases where
>> an
>> > external system can authenticate a user with the digest password but
>> have
>> > no
>> > way of returning an actual password for this CallbackHandler to give it
>> to
>> > WSS4JInterceptor
>> > - authentication is only part of the story, what is really important is
>> > that
>> > the authorization can be done further down the line. I don't think
>> trying
>> > to
>> > do the authorization from the CallbackHandler is a good approach - we
>> > don't
>> > even know the method name to be invoked upon
>> >
>> > Now, perhaps one can even authenticate and authorize from a callback
>> > handler
>> > by somehow getting to the current Message, figuring out the method name,
>> > etc. But IMHO the proposed approach is cleaner and it gives more options
>> > as
>> > to when an authorization should be done due to the fact we have a valid
>> > SecurityContext in scope
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Glen,
On Wed, Apr 7, 2010 at 5:12 PM, Glen Mazza <gl...@gmail.com> wrote:
>
> Sergey, be careful with your first reason--that of using the
> CallbackHandlers
> to *return* passwords, that's an old erroneous design apparently since
> fixed
> in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
> necessarily be used as a reason for doing what you're doing--that process
> should be taken out of CXF instead when it upgrades to the new WSS4J.
>
I'm sorry but this does sounds convincing. You're kind of indicating that
what is proposed
is not good enough ? But you have not said anything about the authorization.
WSS4J is restricting with respects to digests at thje moment but as I said,
we're after the authorization here
>
> Actually, I think Metro does what you want--allows the option for
> container-managed authentication *without* the callbackhandler
> (http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3
> ).
> If you can repeat the same with CXF, great!
>
I really don't follow why you refer to Metro, what is to do with the use of
CXF ?
Sergey
>
> Glen
>
>
> Sergey Beryozkin-5 wrote:
> >
> > There are few problems with depending on CallbackHandlers only :
> >
> > - when passwords have been digested, WSS4JInterceptor requires a clear
> > text
> > password back to verify a digest which is not realistic in cases where an
> > external system can authenticate a user with the digest password but have
> > no
> > way of returning an actual password for this CallbackHandler to give it
> to
> > WSS4JInterceptor
> > - authentication is only part of the story, what is really important is
> > that
> > the authorization can be done further down the line. I don't think trying
> > to
> > do the authorization from the CallbackHandler is a good approach - we
> > don't
> > even know the method name to be invoked upon
> >
> > Now, perhaps one can even authenticate and authorize from a callback
> > handler
> > by somehow getting to the current Message, figuring out the method name,
> > etc. But IMHO the proposed approach is cleaner and it gives more options
> > as
> > to when an authorization should be done due to the fact we have a valid
> > SecurityContext in scope
> >
>
> --
> View this message in context:
> http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
>
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Glen Mazza <gl...@gmail.com>.
Sergey, be careful with your first reason--that of using the CallbackHandlers
to *return* passwords, that's an old erroneous design apparently since fixed
in WSS4J (https://issues.apache.org/jira/browse/WSS-183) that should not
necessarily be used as a reason for doing what you're doing--that process
should be taken out of CXF instead when it upgrades to the new WSS4J.
Actually, I think Metro does what you want--allows the option for
container-managed authentication *without* the callbackhandler
(http://www.jroller.com/gmazza/entry/metro_usernametoken_profile#MetroUT3).
If you can repeat the same with CXF, great!
Glen
Sergey Beryozkin-5 wrote:
>
> There are few problems with depending on CallbackHandlers only :
>
> - when passwords have been digested, WSS4JInterceptor requires a clear
> text
> password back to verify a digest which is not realistic in cases where an
> external system can authenticate a user with the digest password but have
> no
> way of returning an actual password for this CallbackHandler to give it to
> WSS4JInterceptor
> - authentication is only part of the story, what is really important is
> that
> the authorization can be done further down the line. I don't think trying
> to
> do the authorization from the CallbackHandler is a good approach - we
> don't
> even know the method name to be invoked upon
>
> Now, perhaps one can even authenticate and authorize from a callback
> handler
> by somehow getting to the current Message, figuring out the method name,
> etc. But IMHO the proposed approach is cleaner and it gives more options
> as
> to when an authorization should be done due to the fact we have a valid
> SecurityContext in scope
>
--
View this message in context: http://old.nabble.com/Using-WS-Security-UsernameToken-to-authenticate-users-and-populate--SecurityContexts-tp28165583p28167255.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Using WS-Security UsernameToken to authenticate users and
populate SecurityContexts
Posted by Sergey Beryozkin <sb...@gmail.com>.
Glen Mazza asks :
Quote: "Higher level containers should be able to delegate to their own
subsystems for authenticating a user and populating SecurityContext"
I'm not clear on something, why can't that be done (or why would it be
suboptimal/inconvenient for doing that) from the already provided
CallbackHandler anyway--have that class call whatever it needs to for
authentication to occur?
Glen, hope you're ok with me answering here:
There are few problems with depending on CallbackHandlers only :
- when passwords have been digested, WSS4JInterceptor requires a clear text
password back to verify a digest which is not realistic in cases where an
external system can authenticate a user with the digest password but have no
way of returning an actual password for this CallbackHandler to give it to
WSS4JInterceptor
- authentication is only part of the story, what is really important is that
the authorization can be done further down the line. I don't think trying to
do the authorization from the CallbackHandler is a good approach - we don't
even know the method name to be invoked upon
Now, perhaps one can even authenticate and authorize from a callback handler
by somehow getting to the current Message, figuring out the method name,
etc. But IMHO the proposed approach is cleaner and it gives more options as
to when an authorization should be done due to the fact we have a valid
SecurityContext in scope
cheers, Sergey
On Wed, Apr 7, 2010 at 4:02 PM, Alessio Soldano <as...@redhat.com> wrote:
> Hi Sergey,
> needless to say, I really like this.
> Just ping me of course when you move to the JBossWS side of this topic to
> do the tests.
> Cheers
> Alessio
>
>
> Sergey Beryozkin wrote:
>
>> Hi
>>
>> I've been looking recently at extending the CXF WS-Security component such
>> that a current UsernameToken could be used by custom interceptors
>> to authenticate a user with the external security systems and, if
>> possible,
>> provide enough information for CXF to populate a SecurityContext [1] to be
>> used later on for
>> authorization decisions.
>>
>> Here is the approach I've taken so far.
>> A custom interceptor extends
>> AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method
>> it
>> overrides is
>>
>> abstract Subject createSubject(String name, String password, boolean
>> isDigest,
>>
>> String nonce,
>> String created) throws
>> WSSecurityException;
>>
>>
>> For example, see [3].
>>
>> The idea here is that a custom interceptor interfaces whichever way it
>> needs
>> to with the external system and populates a Subject following this simple
>> rule : first Subject principal is the current user (identified by a 'name'
>> argument), followed by one or more Groups this user is a member of.
>> AbstractWSS4JSecurityContextProvidingInterceptor will use this Subject to
>> provide a functional SecurityContext instance.
>>
>> This is the first part, next is how to utilize a SecurityContext and get
>> the
>> expected roles associated one way or the other with a current method to be
>> invoked. There's a number of usual options available here, perhaps even
>> SpringSecurity can be used now that SecurityContext is available, or
>> application code or other custom CXF interceptor can check the known roles
>> against SecurityContext.
>>
>> I've also added AbstractAuthorizingInInterceptor interceptor which custom
>> interceptors can override and return a list of expected roles given a
>> (service) Method to be invoked upon, AbstractAuthorizingInInterceptor will
>> then ask available SecurityContext to match the roles; one concrete
>> implementation is SimpleAuthorizingInterceptor[5], it can be injected with
>> a
>> method specific or class (applying to all methods) roles. Another
>> implementation which I will likely add later on will be injected with a
>> name
>> of annotation such as RolesAlloved and it will introspect a method and its
>> class.
>>
>> Note that I haven't looked into the case when a policy runtimes adds the
>> interceptors yet (as opposed to interceptors being configured form
>> Spring/programmatically). I think an optional contextual property will
>> need
>> to be setup in such cases for users be able to indicate that say an
>> interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
>> etc.
>>
>> I'm going to validate this approach with JBoss CXF. If you have any
>> comments
>> then please let me know.
>>
>> I think we may have a simpler alternative eventually to the way
>> authorization decisions are made. [1]-[3] is specific to ws-security, but
>> [4]-[5] is not
>>
>> cheers, Sergey
>>
>> [1] https://issues.apache.org/jira/browse/CXF-2754
>> [2]
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor.java
>> [3]
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/apache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java
>> [4]
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/AbstractAuthorizingInInterceptor.java
>> [5]
>>
>> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/SimpleAuthorizingInterceptor.java
>>
>>
>>
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>
Re: Using WS-Security UsernameToken to authenticate users and populate
SecurityContexts
Posted by Alessio Soldano <as...@redhat.com>.
Hi Sergey,
needless to say, I really like this.
Just ping me of course when you move to the JBossWS side of this topic
to do the tests.
Cheers
Alessio
Sergey Beryozkin wrote:
> Hi
>
> I've been looking recently at extending the CXF WS-Security component such
> that a current UsernameToken could be used by custom interceptors
> to authenticate a user with the external security systems and, if possible,
> provide enough information for CXF to populate a SecurityContext [1] to be
> used later on for
> authorization decisions.
>
> Here is the approach I've taken so far.
> A custom interceptor extends
> AbstractWSS4JSecurityContextProvidingInterceptor [2] and the only method it
> overrides is
>
> abstract Subject createSubject(String name, String password, boolean isDigest,
>
> String nonce,
> String created) throws WSSecurityException;
>
>
> For example, see [3].
>
> The idea here is that a custom interceptor interfaces whichever way it needs
> to with the external system and populates a Subject following this simple
> rule : first Subject principal is the current user (identified by a 'name'
> argument), followed by one or more Groups this user is a member of.
> AbstractWSS4JSecurityContextProvidingInterceptor will use this Subject to
> provide a functional SecurityContext instance.
>
> This is the first part, next is how to utilize a SecurityContext and get the
> expected roles associated one way or the other with a current method to be
> invoked. There's a number of usual options available here, perhaps even
> SpringSecurity can be used now that SecurityContext is available, or
> application code or other custom CXF interceptor can check the known roles
> against SecurityContext.
>
> I've also added AbstractAuthorizingInInterceptor interceptor which custom
> interceptors can override and return a list of expected roles given a
> (service) Method to be invoked upon, AbstractAuthorizingInInterceptor will
> then ask available SecurityContext to match the roles; one concrete
> implementation is SimpleAuthorizingInterceptor[5], it can be injected with a
> method specific or class (applying to all methods) roles. Another
> implementation which I will likely add later on will be injected with a name
> of annotation such as RolesAlloved and it will introspect a method and its
> class.
>
> Note that I haven't looked into the case when a policy runtimes adds the
> interceptors yet (as opposed to interceptors being configured form
> Spring/programmatically). I think an optional contextual property will need
> to be setup in such cases for users be able to indicate that say an
> interceptor such as [3] has to be used as opposed to WSS4JInInterceptor,
> etc.
>
> I'm going to validate this approach with JBoss CXF. If you have any comments
> then please let me know.
>
> I think we may have a simpler alternative eventually to the way
> authorization decisions are made. [1]-[3] is specific to ws-security, but
> [4]-[5] is not
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/CXF-2754
> [2]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/AbstractWSS4JSecurityContextProvidingInterceptor.java
> [3]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/ws/security/src/test/java/org/apache/cxf/ws/security/wss4j/SimpleSubjectCreatingInterceptor.java
> [4]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/AbstractAuthorizingInInterceptor.java
> [5]
> http://svn.apache.org/repos/asf/cxf/trunk/rt/core/src/main/java/org/apache/cxf/interceptor/security/SimpleAuthorizingInterceptor.java
>
>
--
Alessio Soldano
Web Service Lead, JBoss