You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by St...@faa.gov on 2016/03/09 20:58:42 UTC
STS Behavior Change In CXF 3+?
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
RE: STS Behavior Change In CXF 3+?
Posted by St...@faa.gov.
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:coheigea@apache.org]
Sent: Thursday, March 10, 2016 11:40 AM
To: users@cxf.apache.org
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, <St...@faa.gov> 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
Re: STS Behavior Change In CXF 3+?
Posted by Colm O hEigeartaigh <co...@apache.org>.
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, <St...@faa.gov> 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