Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 72.14.220.157 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=cODAh9I3bNCyci+oJWQvY+rY/0odmHJqXS4LP4JiLtoB0mbxbQmaSSQBa+peSvNwiZ
         IF9kRyFHVVN9sjwSNb1naXWJBWe/NWTY5TYUIKlIpgXjg3xwnBs/wrjrMliRu1b5GH6X
         bFOVktxB19op43sbBHDYe7K3A5fC6zjNA/GlA=
MIME-Version: 1.0
In-Reply-To: <00b501cadbd9$0356b240$0a0416c0$@org>
References: <v2z602da591004070711g45bd754i14461fd9aa7c2313@mail.gmail.com>
	 <005f01cad692$a435f7d0$eca1e770$@org>
	 <j2j602da591004080909kd2db5e61v7fe502d7c60ecf02@mail.gmail.com>
	 <00b501cadbd9$0356b240$0a0416c0$@org>
Date: Thu, 15 Apr 2010 14:34:15 +0100
Message-ID: <o2n602da591004150634mcc690730j9d49b42f43365281@mail.gmail.com>
Subject: Re: Using WS-Security UsernameToken to authenticate users and
	populate SecurityContexts
From: Sergey Beryozkin <sberyozkin@gmail.com>
To: dev@cxf.apache.org
Content-Type: multipart/alternative; boundary=001485f5ce120137c20484468df4

--001485f5ce120137c20484468df4
Content-Type: text/plain; charset=ISO-8859-1

Hi David

On Wed, Apr 14, 2010 at 2:46 PM, David Valeri <dvaleri@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 <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/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>
> >
> >
>
>

--001485f5ce120137c20484468df4--