Populating security context principal from actAs attribute

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Populating security context principal from actAs attribute

Andreas Vallen
Hi,

after upgrading from cxd-fediz 3.1.1 to 3.1.2, and to cxd 3.1.11 in the
process our service which consumes actAs tokens issued by the STS broke
because the security context principal is now being initialized with the
identity of the requestor which is the system that requested the
IssuedToken - identified by the DN of its public key.

The cause of this issue likely is the fix done by
https://issues.apache.org/jira/browse/CXF-7099 - before that the actual
actAs user was set as the subject NameID value of the issued token.

Is the a way to configure the service to evaluate the actAs attribute
instead of the subject NameID as before in order to determine the user
identity?

Best,
Andreas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Populating security context principal from actAs attribute

coheigea
Administrator
Hi Andreas,

Yes, you can simply override the DefaultSubjectProvider.getPrincipal method
+ return the principal from
providerParameters.getTokenRequirements().getActAs() instead:

https://github.com/apache/cxf/blob/master/services/sts/sts-core/src/main/java/org/apache/cxf/sts/token/provider/DefaultSubjectProvider.java#L122

Then set this new implementation on the SAMLTokenProvider:

https://github.com/apache/cxf/blob/master/services/sts/sts-core/src/main/java/org/apache/cxf/sts/token/provider/SAMLTokenProvider.java#L229

Colm.

On Wed, Jul 26, 2017 at 10:47 PM, Andreas Vallen <[hidden email]>
wrote:

> Hi,
>
> after upgrading from cxd-fediz 3.1.1 to 3.1.2, and to cxd 3.1.11 in the
> process our service which consumes actAs tokens issued by the STS broke
> because the security context principal is now being initialized with the
> identity of the requestor which is the system that requested the
> IssuedToken - identified by the DN of its public key.
>
> The cause of this issue likely is the fix done by
> https://issues.apache.org/jira/browse/CXF-7099 - before that the actual
> actAs user was set as the subject NameID value of the issued token.
>
> Is the a way to configure the service to evaluate the actAs attribute
> instead of the subject NameID as before in order to determine the user
> identity?
>
> Best,
> Andreas
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Populating security context principal from actAs attribute

Andreas Vallen
Hi Colm,

It seems the suggested changes would apply at the STS - but I'm happy with
the new behavior of the STS as introduced by CXF-7099 (right?) - I just
want to be able to properly evaluate the issued actAs token in the service,
which is the relying party for this token.

Would you also have any guidance on customization or configuration in the
service so that it looks for the principal at the new location whithin the
SAML assertion?

Best,
Andreas




On Thu, Jul 27, 2017 at 1:28 PM, Colm O hEigeartaigh <[hidden email]>
wrote:

> Hi Andreas,
>
> Yes, you can simply override the DefaultSubjectProvider.getPrincipal
> method
> + return the principal from
> providerParameters.getTokenRequirements().getActAs() instead:
>
> https://github.com/apache/cxf/blob/master/services/sts/sts-
> core/src/main/java/org/apache/cxf/sts/token/provider/
> DefaultSubjectProvider.java#L122
>
> Then set this new implementation on the SAMLTokenProvider:
>
> https://github.com/apache/cxf/blob/master/services/sts/sts-
> core/src/main/java/org/apache/cxf/sts/token/provider/
> SAMLTokenProvider.java#L229
>
> Colm.
>
> On Wed, Jul 26, 2017 at 10:47 PM, Andreas Vallen <[hidden email]
> >
> wrote:
>
> > Hi,
> >
> > after upgrading from cxd-fediz 3.1.1 to 3.1.2, and to cxd 3.1.11 in the
> > process our service which consumes actAs tokens issued by the STS broke
> > because the security context principal is now being initialized with the
> > identity of the requestor which is the system that requested the
> > IssuedToken - identified by the DN of its public key.
> >
> > The cause of this issue likely is the fix done by
> > https://issues.apache.org/jira/browse/CXF-7099 - before that the actual
> > actAs user was set as the subject NameID value of the issued token.
> >
> > Is the a way to configure the service to evaluate the actAs attribute
> > instead of the subject NameID as before in order to determine the user
> > identity?
> >
> > Best,
> > Andreas
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Populating security context principal from actAs attribute

coheigea
Administrator
Hi Andreas,

You have two options. You could switch to use OnBehalfOf instead of ActAs -
OnBehalfOf uses the new principal name as the Subject of the assertion, as
ActAs used to do prior to CXF-7099. Or otherwise you'll have to configure
the security context on the receiving side to set up the security context
with the principal name from the Attribute instead.

There is a configuration tag called "ws-security.security.context.creator"
which allows you to plug in a WSS4JSecurityContextCreator implementation:

https://github.com/apache/cxf/blob/3.1.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/SecurityConstants.java#L299
https://github.com/apache/cxf/blob/3.1.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/WSS4JSecurityContextCreator.java

The default implementation is here:

https://github.com/apache/cxf/blob/3.1.x-fixes/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/DefaultWSS4JSecurityContextCreator.java

Colm.

On Thu, Jul 27, 2017 at 1:21 PM, Andreas Vallen <[hidden email]>
wrote:

> Hi Colm,
>
> It seems the suggested changes would apply at the STS - but I'm happy with
> the new behavior of the STS as introduced by CXF-7099 (right?) - I just
> want to be able to properly evaluate the issued actAs token in the service,
> which is the relying party for this token.
>
> Would you also have any guidance on customization or configuration in the
> service so that it looks for the principal at the new location whithin the
> SAML assertion?
>
> Best,
> Andreas
>
>
>
>
> On Thu, Jul 27, 2017 at 1:28 PM, Colm O hEigeartaigh <[hidden email]>
> wrote:
>
>> Hi Andreas,
>>
>> Yes, you can simply override the DefaultSubjectProvider.getPrincipal
>> method
>> + return the principal from
>> providerParameters.getTokenRequirements().getActAs() instead:
>>
>> https://github.com/apache/cxf/blob/master/services/sts/sts-c
>> ore/src/main/java/org/apache/cxf/sts/token/provider/DefaultS
>> ubjectProvider.java#L122
>>
>> Then set this new implementation on the SAMLTokenProvider:
>>
>> https://github.com/apache/cxf/blob/master/services/sts/sts-c
>> ore/src/main/java/org/apache/cxf/sts/token/provider/SAMLToke
>> nProvider.java#L229
>>
>> Colm.
>>
>> On Wed, Jul 26, 2017 at 10:47 PM, Andreas Vallen <
>> [hidden email]>
>> wrote:
>>
>> > Hi,
>> >
>> > after upgrading from cxd-fediz 3.1.1 to 3.1.2, and to cxd 3.1.11 in the
>> > process our service which consumes actAs tokens issued by the STS broke
>> > because the security context principal is now being initialized with the
>> > identity of the requestor which is the system that requested the
>> > IssuedToken - identified by the DN of its public key.
>> >
>> > The cause of this issue likely is the fix done by
>> > https://issues.apache.org/jira/browse/CXF-7099 - before that the actual
>> > actAs user was set as the subject NameID value of the issued token.
>> >
>> > Is the a way to configure the service to evaluate the actAs attribute
>> > instead of the subject NameID as before in order to determine the user
>> > identity?
>> >
>> > Best,
>> > Andreas
>> >
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Loading...