CXF STS ActAs / Advice Subject Handling

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

CXF STS ActAs / Advice Subject Handling

Stephen.CTR.Chappell
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
Reply | Threaded
Open this post in threaded view
|

Re: CXF STS ActAs / Advice Subject Handling

coheigea
Administrator
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, <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: CXF STS ActAs / Advice Subject Handling

Stephen.CTR.Chappell
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:[hidden email]]
Sent: Thursday, February 16, 2017 11:57 AM
To: [hidden email]
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, <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: CXF STS ActAs / Advice Subject Handling

coheigea
Administrator
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, <[hidden email]> 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:[hidden email]]
> Sent: Thursday, February 16, 2017 11:57 AM
> To: [hidden email]
> 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, <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

RE: CXF STS ActAs / Advice Subject Handling

Stephen.CTR.Chappell
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:[hidden email]]
Sent: Friday, February 17, 2017 4:41 AM
To: [hidden email]
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, <[hidden email]> 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:[hidden email]]
> Sent: Thursday, February 16, 2017 11:57 AM
> To: [hidden email]
> 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, <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: CXF STS ActAs / Advice Subject Handling

coheigea
Administrator
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, <[hidden email]> 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:[hidden email]]
> Sent: Friday, February 17, 2017 4:41 AM
> To: [hidden email]
> 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, <[hidden email]> 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:[hidden email]]
> > Sent: Thursday, February 16, 2017 11:57 AM
> > To: [hidden email]
> > 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, <[hidden email]> 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