t;>>> > > credentials get authenticated and what needs to end up in the
>>>> security
>>>> > > context.
>>>> >
>>>> > I suppose AbstractWSS4JSecurityContextProvidingInterceptor subclasses
>>>> > shou
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:sberyoz...@gmail.com]
> Sent: Friday, April 23, 2010 1:03 PM
> To: dev@cxf.apache.org
>
; -Original Message-
> From: Sergey Beryozkin [mailto:sberyoz...@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 b
eryoz...@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
>
...@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 i
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.
>> >>> >
>> >>
gt;
> This approach can easily work with Spring Security as an
> AuthenticationService implementation.
>
>
sounds great indeed.
thanks, Sergey
> -Original Message-
> From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
> Sent: Wednesday, April 21, 2010 5:47 PM
> To
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
ith 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
>>&
>> 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
>>>> > >
nd 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.
>>> >
>>> > >
> >
>> > > 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 l
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. Perhap
pability 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
>
mail.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 wrote:
> Sergey,
>
> I think th
> 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
> > > auth
uthenticate
> > 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 comp
;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:sberyoz...@gmail.com]
> Sent: Wednesday, April 07, 2010 10:11 AM
> To: dev@cxf.apache.org
>
Beryozkin [mailto:sberyoz...@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
tever 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 authenticati
re 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-
erhaps 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.
>>
>>
>
proach - 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.
>>
>>
>
erhaps 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
lback
> 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
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
C
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 us
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
use
28 matches
Mail list logo
