No, I'm not configuring an AttributeStatementProvider, at least not yet. Bearer tokens are an edge case for us so I probably haven't given them quite enough attention. The default AttributeStatement should be fine for us in this case though.
Thanx, Stephen W. Chappell -----Original Message----- From: Colm O hEigeartaigh [mailto:[email protected]] Sent: Thursday, March 10, 2016 11:40 AM To: [email protected] Subject: Re: STS Behavior Change In CXF 3+? 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 AttributeStatement. Colm. On Wed, Mar 9, 2016 at 8:58 PM, <[email protected]> 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=" > http://cxf.apache.org/sts";> > <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 http://coders.talend.com
