You're right, I was working from memory instead of looking at the code.
DefaultSubjectProvider gets the Principal from the ActAs if there is one ...
public SubjectBean getSubject(
TokenProviderParameters providerParameters, Document doc, byte[] secret
) {
...
if (providerParameters.getTokenRequirements().getOnBehalfOf()
!= null) {
...
} else if (providerParameters.getTokenRequirements().getActAs() !=
null) {
receivedToken =
providerParameters.getTokenRequirements().getActAs();
if (receivedToken.getState().equals(STATE.VALID)) {
principal = receivedToken.getPrincipal();
}
} else if ...
In my case, this has the same effect as pulling it from the Advice.
It's not clear to me from the Jira or the email thread what the actual fix is
here? I haven't looked at the test case yet. I do have a version of STS that I
upleveled to CXF 3.1.4, but I don't recall any significantly different behavior
in our ActAs use cases, unless of course I missed something.
Thanx,
SwC
-----Original Message-----
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Friday, February 17, 2017 4:41 AM
To: users@cxf.apache.org
Subject: Re: CXF STS ActAs / Advice Subject Handling
Hi Stephen,
The DefaultSubjectProvider doesn't interact with Advice at all from what I can
see, so I think what you are describing below must be some custom extension?
By the way, there was a bug fixed in how we handle ActAs in the STS since
2.7.x:
https://issues.apache.org/jira/browse/CXF-7099
Colm.
On Thu, Feb 16, 2017 at 5:45 PM, <stephen.ctr.chapp...@faa.gov> wrote:
> If an RST contains an ActAs element that contains a SAML Assertion,
> the STS is supposed to stick that Assertion into the Advice element of
> the new Assertion it is creating. The STS doesn't do that by default
> but as I recall I implemented a SAML custom handler to do that. What
> the STS does do by default (in DefaultSubjectProvider), is if the
> generated Assertion has Advice, then the Subject/NameID element in the
> generated Assertion is set to be the same as the Subject of the Advice
> Assertion. I was looking for a specification reason for why that was,
> because I was getting asked about it; I think I found what I was
> looking for but of course I can't find it now :P
>
> Thanx,
> SwC
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Thursday, February 16, 2017 11:57 AM
> To: users@cxf.apache.org
> Subject: Re: CXF STS ActAs / Advice Subject Handling
>
> Hi Stephen,
>
> The STS does not currently handle "Advice" Elements by default. What
> relationship is there in your use-case between "Advice" and "ActAs"?
>
> Colm.
>
> On Fri, Feb 10, 2017 at 1:23 PM, <stephen.ctr.chapp...@faa.gov> wrote:
>
> > Hi -
> >
> > When I send an RST to my STS (CXF 2.7.14) to get a holder-of-key
> > token with Advice, it looks like the token I get back has a Subject
> > that matches the X509 cert in the Advice rather than its own cert.
> > It looks like it's supposed to be this way based on what I see in
> > DefaultSubjectProvider, is that correct? Is that spelled out in
> > ws-trust or one of the saml specs somewhere? It makes sense to me
> > that it should work that way, but I'm getting some questions about
> > it and would like be able to point to something that says why it is that
> > way.
> >
> > Thanx,
> >
> > Stephen W. Chappell
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
