The default behaviour prior to the fix for CXF-7099 was to include the
ActAs principal as the Subject name of the Assertion. Since then, the
subject name of the Assertion is the authenticated principal associated
with the request, and the ActAs principal is inserted into the Assertion as
an attribute.

Colm.

On Fri, Feb 17, 2017 at 1:40 PM, <stephen.ctr.chapp...@faa.gov> wrote:

> 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
>



-- 
Colm O hEigeartaigh

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

Reply via email to