cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <>
Subject Re: STS Behavior Change In CXF 3+?
Date Thu, 10 Mar 2016 16:40:10 GMT
Hi Stephen,

It should only add in that AttributeStatement if no other Statements are
added into the generated assertion. It did have the behaviour that you
specified, where the default AttributeStatement was also added to the
Assertion, but this was fixed before CXF 3.1.4. Are you configuring a
custom AttributeStatementProvider in the SAMLTokenProvider, or are you
handling Claims? If not then it will just add the default


On Wed, Mar 9, 2016 at 8:58 PM, <> wrote:

> I've recently done some work migrating my STS implementation from using
> CXF 2.7.14 up to 3.1.4. In testing the upleveled STS, I noticed that a
> change crept in somewhere along the way when requesting a bearer token - in
> CXF 3, the returned token has an additional AttributeStatement:
> <saml2:AttributeStatement>
>                 <saml2:Attribute Name="token-requestor" NameFormat="
>                                 <saml2:AttributeValue
> xsi:type="xsd:string">authenticated</saml2:AttributeValue>
>                 </saml2:Attribute>
> </saml2:AttributeStatement>
> I don't think this is a problem for me necessarily, but it was unexpected.
> Is there a way to suppress the inclusion of this attribute in the token?
> Or, some rationale for why I maybe shouldn't?
> Thanx,
> Stephen W. Chappell

Colm O hEigeartaigh

Talend Community Coder

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message