previous X509 auth result contains subject with no public credentials

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

previous X509 auth result contains subject with no public credentials

Bobby Lawrence

Hello all – I have a strange issue here that I’m hoping someone can help with.  I’m running IdP 3.4.7 on Tomcat 8.0.53 and trying to get X509 authentication working so that our users can authenticate with their smart cards.
It seems that everything works fine on the first authentication attempt…the IdP trusts my cert, extracts the X500Principal which is added to the principals of the subject and adds the certificate itself to the public credentials of the subject.  The DN on the certificate doesn’t contain my LDAP username, but it does have a SubjectAltName that does.  No problem for the IdP tho because the c14n/x500 flow extracts the subject alternative name from the certificate and constructs a c14n principal name which is used to fetch attributes from LDAP.  All very well documented and working as expected.  Yay.
However when I attempt to log into another SP and the IdP re-uses my previous X509 authentication result, the subject from the previous X509 authentication result has no public credentials…the set returned from the ‘getPublicCredentials’ method is empty.  The set of principals (returned from the ‘getPrincipals’ method) seems fine tho because it is populated with all the principals from the previous authentication.  The missing public credentials means that the c14/x500 canonicalization process cannot fetch the username from the subject alternative name and because of that, the IdP cannot lookup my attributes from LDAP.
Has anyone encountered this before? 

Thanks in advance.

--

Bobby Lawrence

Jefferson Lab MIS


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: previous X509 auth result contains subject with no public credentials

Bobby Lawrence

Well – it appears I may have found my problem, but I don’t know how to solve it.

Per the Javadoc for javax.security.auth.Subject (https://docs.oracle.com/javase/8/docs/api/javax/security/auth/Subject.html):

 

“While the Principals associated with the Subject are serialized, the credentials associated with the Subject are not”

 

So it seems that when the AuthenticationResult is serialized to the session, all the credentials are lost.

From what I know about how Java app servers and the IdP work, I have a couple solutions – none of which are very ideal.

I can create my own version of “net.shibboleth.idp.authn.impl.ValidateX509Certificate” which changes the implementation of the “populateSubject” method and adds a net.shibboleth.idp.authn.principal.UsernamePrincipal for each of the certificate subject alternative names.  Maybe in a similar manner as the “net.shibboleth.idp.authn.impl. X500SubjectCanonicalization” class does and basically performing the subject canonicalization before the c14 process is even performed.  I could even use a Predicate to determine if/when this should happen or even for determining if a SubjectAltName should be used instead of the X500Principal.  While all of this seems do-able, there is no easy way make the IdP use my custom class without either overriding the impl class with my own version (adding to the Tomcat system classpath so it takes precedence), or changing system/flows/authn/x509-internal-authn-beans.xml and/or system/flows/authn/x509-internal-authn-flow.xml file to use a custom class.  Both of these are ‘system’ config files and not meant to be changed.

Obviously both of these solutions are a hack to solve my problem and neither sit well with me.

 

Does anyone have any ideas?

 

From: Bobby Lawrence
Sent: Friday, November 20, 2020 4:35 PM
To: Shib Users <[hidden email]>
Subject: previous X509 auth result contains subject with no public credentials

 

Hello all – I have a strange issue here that I’m hoping someone can help with.  I’m running IdP 3.4.7 on Tomcat 8.0.53 and trying to get X509 authentication working so that our users can authenticate with their smart cards.
It seems that everything works fine on the first authentication attempt…the IdP trusts my cert, extracts the X500Principal which is added to the principals of the subject and adds the certificate itself to the public credentials of the subject.  The DN on the certificate doesn’t contain my LDAP username, but it does have a SubjectAltName that does.  No problem for the IdP tho because the c14n/x500 flow extracts the subject alternative name from the certificate and constructs a c14n principal name which is used to fetch attributes from LDAP.  All very well documented and working as expected.  Yay.
However when I attempt to log into another SP and the IdP re-uses my previous X509 authentication result, the subject from the previous X509 authentication result has no public credentials…the set returned from the ‘getPublicCredentials’ method is empty.  The set of principals (returned from the ‘getPrincipals’ method) seems fine tho because it is populated with all the principals from the previous authentication.  The missing public credentials means that the c14/x500 canonicalization process cannot fetch the username from the subject alternative name and because of that, the IdP cannot lookup my attributes from LDAP.
Has anyone encountered this before? 

Thanks in advance.

--

Bobby Lawrence

Jefferson Lab MIS


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: previous X509 auth result contains subject with no public credentials

Cantor, Scott E.
My recollection is that under ordinary conditions, c14n doesn't apply to reuse of a result. When the master flow reuses a result for SSO, the finalize step pulls the principal name from the session rather than applying c14n to the result.

The exception would be MFA (if the MFA flow itself is forced to run and not just get reused itself), in which case, there's probably an edge case there that would have to be addressed through plugging in a more complex merging function, but that function still wouldn't have the certificate available after the first time. However, it could populate more information into the merged Subject on the initial go-round to preserve enough information and/or add in additional Principals that already get serialized.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: previous X509 auth result contains subject with no public credentials

Cantor, Scott E.
(This is aside from the suggestion you made...yes, I think it's sensible to file a RFE to allow a sort of "end run" around c14n to populate the initial result with information from the certificate, simply because it would simplify other cases such as the MFA example. But that's not there now, no.)

´╗┐On 11/20/20, 6:05 PM, "users on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

    My recollection is that under ordinary conditions, c14n doesn't apply to reuse of a result. When the master flow reuses a result for SSO, the finalize step pulls the principal name from the session rather than applying c14n to the result.

    The exception would be MFA (if the MFA flow itself is forced to run and not just get reused itself), in which case, there's probably an edge case there that would have to be addressed through plugging in a more complex merging function, but that function still wouldn't have the certificate available after the first time. However, it could populate more information into the merged Subject on the initial go-round to preserve enough information and/or add in additional Principals that already get serialized.

    -- Scott


    --
    For Consortium Member technical support, see https://urldefense.com/v3/__https://wiki.shibboleth.net/confluence/x/coFAAg__;!!KGKeukY!i4SH9GcAxfQwmxmieRYEB_f8CuGCnzyNQMnnWBMuIgm7dbsH0rLJjmVA8722hfw$ 
    To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: previous X509 auth result contains subject with no public credentials

Bobby Lawrence
In reply to this post by Cantor, Scott E.
So I guess I should have mentioned that I am actually using the MFA flow with X509 auth as a second factor.  I actually it set up so that the password flow runs first, then a script determines if the user needs a second factor and if so, I transition to a custom flow where the user can select what second factor they want to use (OTP or certificate/smart card).  When they make their choice, the MFA flow runs that selection last.  It may be that my problem is that c14n/x500 runs first and sets the principal name instead of letting the c14n/simple flow fetch the UsernamePrincipal from the other authentication result?  I might try putting the c14n/simple first in the list...

It might be nice if the different contexts (c14n for example) could be re-used, but I'm pretty sure only the authentication results are persisted in the session...am I right?  Honestly, when I first started using the system some years ago I was under the impression that everything would be re-used and most things wouldn't need to be re-run (like attribute resolution) but after looking though the source code, it looks like that isn't the case.

Anyway - aside from my suggestions or somehow re-creating the entire X509 authn as a custom flow, are you saying that I'm kinda stuck?  

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Friday, November 20, 2020 6:05 PM
To: Shib Users <[hidden email]>
Subject: [EXTERNAL] Re: previous X509 auth result contains subject with no public credentials

My recollection is that under ordinary conditions, c14n doesn't apply to reuse of a result. When the master flow reuses a result for SSO, the finalize step pulls the principal name from the session rather than applying c14n to the result.

The exception would be MFA (if the MFA flow itself is forced to run and not just get reused itself), in which case, there's probably an edge case there that would have to be addressed through plugging in a more complex merging function, but that function still wouldn't have the certificate available after the first time. However, it could populate more information into the merged Subject on the initial go-round to preserve enough information and/or add in additional Principals that already get serialized.

-- Scott


--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=CJqEzB1piLOyyvZjb8YUQw&r=YbL7Tj_EqBW9abl6xEy1bg&m=Kcf_XibDYgo7u-8BWG614_wN1gLoA0PxWyLtv_qddZo&s=Jx7ld7TdhpqRj4qfHMpznS8f5D6yIWMLBDu89kb-nXw&e= 
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: previous X509 auth result contains subject with no public credentials

Cantor, Scott E.
On 11/20/20, 7:08 PM, "Bobby Lawrence" <[hidden email]> wrote:

>    So I guess I should have mentioned that I am actually using the MFA flow with X509 auth as a second factor.  I actually it
> set up so that the password flow runs first, then a script determines if the user needs a second factor and if so, I transition
> to a custom flow where the user can select what second factor they want to use (OTP or certificate/smart card).

Certificates are not really historically a "second factor". That doesn't really have anything to do with it, I just thought it was interesting.

>  When they make their choice, the MFA flow runs that selection last.  It may be that my problem is that c14n/x500 runs
> first and sets the principal name instead of letting the c14n/simple flow fetch the UsernamePrincipal from the other
> authentication result?  I might try putting the c14n/simple first in the list...

They all run until one succeeds, that only impacts the order they're tried.

As I said, this case applies because re-running the factors from within an MFA rule reuses the embedded results that have already been serialized and so are missing the information that's documented to be missing when that happens.

>    It might be nice if the different contexts (c14n for example) could be re-used, but I'm pretty sure only the
> authentication results are persisted in the session...am I right?

Yes. Contexts are a per-request concept, they never get serialized.

>    Anyway - aside from my suggestions or somehow re-creating the entire X509 authn as a custom flow, are you saying
> that I'm kinda stuck?  

No, I'm saying you need a custom merging function. The MFA documentation covers the signature of the function, you have to build you own final result. If you're already digging into the code you can probably find the default function it uses as an example.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: previous X509 auth result contains subject with no public credentials

Bobby Lawrence
> Certificates are not really historically a "second factor". That doesn't really have anything to do with it, I just thought it was interesting.

I've got the shibboleth.authn.X509.TrustEngine set up so that it only trusts certificates for the various smart cards we use at my site (PIV-C and PIV-I).  Usage of these certificates requires a hardware reader and a PIN so its kinda 2FA itself.


>> It may be that my problem is that c14n/x500 runs first and sets the
>> principal name instead of letting the c14n/simple flow fetch the UsernamePrincipal from the other authentication result?  I might try putting the c14n/simple first in the list...

> They all run until one succeeds, that only impacts the order they're tried.
> As I said, this case applies because re-running the factors from within an MFA rule reuses the embedded results that have already been serialized > and so are missing the information that's documented to be missing when that happens.

Its worth noting that by moving the c14n/simple subject canonicalization flow up before the c14n/x500 one, I kind of solve my problem.  I guess that works because my MFA setup requires the password flow first which adds a UsernamePrincipal to the subject which can be extracted with the c14n/simple flow and since the simple flow proceeds, the username is used for the subject principal name.  I say "kind of" because I still end up with this issue in one certain situation (explained next).


> No, I'm saying you need a custom merging function. The MFA documentation covers the signature of the function, you have to build you own final > result. If you're already digging into the code you can probably find the default function it uses as an example.

I've seen the merging function and I will look into creating a custom one as I've seen if the password flow is skipped (I have x509 available as an 'extended' password flow option), then I'm in the same boat....the UsernamePrincipal doesn't exist so the X500Principal is the only one that can be used for subject canonicalization and after the first auth, there is no certificate in the subject to fetch the alternative names from.

Thanks for your help Scott!

--Bobby
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: previous X509 auth result contains subject with no public credentials

Cantor, Scott E.
On 11/23/20, 11:15 AM, "users on behalf of Bobby Lawrence" <[hidden email] on behalf of [hidden email]> wrote:

>    I've seen the merging function and I will look into creating a custom one as I've seen if the password flow is skipped (I
> have x509 available as an 'extended' password flow option), then I'm in the same boat....the UsernamePrincipal doesn't
> exist so the X500Principal is the only one that can be used for subject canonicalization and after the first auth, there is no
> certificate in the subject to fetch the alternative names from.

Right. If Password was used, the merged Subject will include the simple-compatible Principal but if it's not used, and X.509 gets reused, you'll get a Subject without anything in it to base the c14n on.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: previous X509 auth result contains subject with no public credentials

Bobby Lawrence
Ok - I've got a custom merging strategy implemented but to make it work, I had to do something I didn't quite expect.  Originally this custom merge function simply replaced any X500Principal in the merged Subject with a UsernamePrincipal containing the subject alternative name fetched from the certificate found in the public credentials.  However just doing this on the merged result didn't change anything after the first authn.  The second time through, I still had the same problem.

I think the issue is the fact that a function in net.shibboleth.idp.authn.impl.PopulateMultiFactorAuthenticationContext (DefaultResultLookupStrategy) fetches only the AuthenticationResultPrincipal(s) from the subject and uses those to populate the MFA context with active results.  Its from those active results that the new MFA authentication result is finalized.  So even though my custom merging function replaces the X500Principal in the subject, it still existed in the AuthenticationResultPrincipal and during re-use, everything from the serialized AuthenticationResult subject is effectively discarded except for the AuthenticationResultPrincipal(s)....only the principals from the Subject are serialized (no credentials) and out of those principals, only the AuthenticationResultPrincipal is re-used.
To make it work, I had to remove the X500Principal and add my UsernamePrincipal on the X509 AuthenticationResult subject directly....before all its principals are added to the new 'merged' subject created by net.shibboleth.idp.authn.impl.FinalizeMultiFactorAuthentication.

So again - this works but while doing this I realized that this only works because I'm using the MFA flow.  If I was using the X509 flow directly without all the MFA pre- and post- processing, this wouldn't work.  It would be nice if there was a way to have some type of finer control of the AuthenticationResult created by each authn flow.  Perhaps a function that could be injected into the flow processing that would be executed in net.shibboleth.idp.authn.AbstractValidationAction in its "buildAuthenticationResult" method after the subject for that flow is populated but before an authentication result is created with that subject.  Scott - maybe this is what you were referring to when you mentioned creating an RFE?  For some reason I don't think so because you mentioned the c14n flow in that comment, but that all happens after the authn flow completes...
 
Anyway - thanks again for your invaluable help Scott

-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, November 23, 2020 11:34 AM
To: Shib Users <[hidden email]>
Subject: [EXTERNAL] Re: previous X509 auth result contains subject with no public credentials

On 11/23/20, 11:15 AM, "users on behalf of Bobby Lawrence" <[hidden email] on behalf of [hidden email]> wrote:

>    I've seen the merging function and I will look into creating a
> custom one as I've seen if the password flow is skipped (I have x509
> available as an 'extended' password flow option), then I'm in the same
> boat....the UsernamePrincipal doesn't exist so the X500Principal is the only one that can be used for subject canonicalization and after the first auth, there is no certificate in the subject to fetch the alternative names from.

Right. If Password was used, the merged Subject will include the simple-compatible Principal but if it's not used, and X.509 gets reused, you'll get a Subject without anything in it to base the c14n on.

-- Scott


--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=CJqEzB1piLOyyvZjb8YUQw&r=YbL7Tj_EqBW9abl6xEy1bg&m=_A8_C6SgnBpuKqyDWemh6A8b82-i-X2dyGVWs2L28Jk&s=eSYGto8tBOIsiM_iu0ddqZiDaiXBm8BrWv8W0geLM4k&e=
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: previous X509 auth result contains subject with no public credentials

Cantor, Scott E.
On 11/23/20, 3:58 PM, "users on behalf of Bobby Lawrence" <[hidden email] on behalf of [hidden email]> wrote:

>    I think the issue is the fact that a function in net.shibboleth.idp.authn.impl.PopulateMultiFactorAuthenticationContext
> (DefaultResultLookupStrategy) fetches only the AuthenticationResultPrincipal(s) from the subject and uses those to
> populate the MFA context with active results.  Its from those active results that the new MFA authentication result is
> finalized.  So even though my custom merging function replaces the X500Principal in the subject, it still existed in the
> AuthenticationResultPrincipal and during re-use, everything from the serialized AuthenticationResult subject is effectively
> discarded except for the AuthenticationResultPrincipal(s)

Yes, that's a fair point. I've never had to do this so I don't fully appreciate the complexities at this point. I think you're correct that even if the merging function itself produces a usable result, that doesn't help because the original results aren't altered by that and they're still a problem.

>    To make it work, I had to remove the X500Principal and add my UsernamePrincipal on the X509 AuthenticationResult
> subject directly....before all its principals are added to the new 'merged' subject created by
> net.shibboleth.idp.authn.impl.FinalizeMultiFactorAuthentication.

You don't have to remove anything, it's the addition of the UsernamePrincipal that allows the "simple" method to work. The X500Principal won't hurt anything. Flows just silently skip themselves if they can't understand the Subject's contents.

>    So again - this works but while doing this I realized that this only works because I'm using the MFA flow.  If I was using
> the X509 flow directly without all the MFA pre- and post- processing, this wouldn't work.

Yes, it would, because if you were doing that, c14n would simply not happen again on reuse/SSO. What you're seeing is a result of the MFA usage, it doesn't happen normally that way. That's why it didn't show up with testing. I realized you were using MFA because of that before you actually confirmed it.

>  Scott - maybe this is what you were referring to when you mentioned creating an RFE?  For some reason I don't think so
> because you mentioned the c14n flow in that comment, but that all happens after the authn flow completes...

I think there are multiple ways of enhancing things to address the problem, I would have to study things more to determine the best way to proceed. Adding a function point to customize the results is probably a better general answer, but there's still the fundamental problem of having to serialize things that aren't friendly to handle (though certificates should be doable). Just because something gets added doesn't mean it will actually get serialized. In effect, converting the contents to a UsernamePrincipal up front is essentially a form of c14n since that just forces things to get handled by the "simple" c14n flow, which is in some sense just the no-op case.

But it's fairly important an issue get filed or it will be forgotten, I'm not really working on this problem at the moment and I won't remember to go back and get into it.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: previous X509 auth result contains subject with no public credentials

Bobby Lawrence
Ok - I will file an RFE with some of the major details of this thread and link to this thread itself....is this the correct link?
https://shibboleth.1660669.n2.nabble.com/previous-X509-auth-result-contains-subject-with-no-public-credentials-td7648022.html


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, November 23, 2020 4:25 PM
To: Shib Users <[hidden email]>
Subject: [EXTERNAL] Re: previous X509 auth result contains subject with no public credentials

On 11/23/20, 3:58 PM, "users on behalf of Bobby Lawrence" <[hidden email] on behalf of [hidden email]> wrote:

>    I think the issue is the fact that a function in
> net.shibboleth.idp.authn.impl.PopulateMultiFactorAuthenticationContext
> (DefaultResultLookupStrategy) fetches only the
> AuthenticationResultPrincipal(s) from the subject and uses those to
> populate the MFA context with active results.  Its from those active
> results that the new MFA authentication result is finalized.  So even
> though my custom merging function replaces the X500Principal in the
> subject, it still existed in the AuthenticationResultPrincipal and
> during re-use, everything from the serialized AuthenticationResult
> subject is effectively discarded except for the
> AuthenticationResultPrincipal(s)

Yes, that's a fair point. I've never had to do this so I don't fully appreciate the complexities at this point. I think you're correct that even if the merging function itself produces a usable result, that doesn't help because the original results aren't altered by that and they're still a problem.

>    To make it work, I had to remove the X500Principal and add my
> UsernamePrincipal on the X509 AuthenticationResult subject
> directly....before all its principals are added to the new 'merged' subject created by net.shibboleth.idp.authn.impl.FinalizeMultiFactorAuthentication.

You don't have to remove anything, it's the addition of the UsernamePrincipal that allows the "simple" method to work. The X500Principal won't hurt anything. Flows just silently skip themselves if they can't understand the Subject's contents.

>    So again - this works but while doing this I realized that this
> only works because I'm using the MFA flow.  If I was using the X509 flow directly without all the MFA pre- and post- processing, this wouldn't work.

Yes, it would, because if you were doing that, c14n would simply not happen again on reuse/SSO. What you're seeing is a result of the MFA usage, it doesn't happen normally that way. That's why it didn't show up with testing. I realized you were using MFA because of that before you actually confirmed it.

>  Scott - maybe this is what you were referring to when you mentioned
> creating an RFE?  For some reason I don't think so because you mentioned the c14n flow in that comment, but that all happens after the authn flow completes...

I think there are multiple ways of enhancing things to address the problem, I would have to study things more to determine the best way to proceed. Adding a function point to customize the results is probably a better general answer, but there's still the fundamental problem of having to serialize things that aren't friendly to handle (though certificates should be doable). Just because something gets added doesn't mean it will actually get serialized. In effect, converting the contents to a UsernamePrincipal up front is essentially a form of c14n since that just forces things to get handled by the "simple" c14n flow, which is in some sense just the no-op case.

But it's fairly important an issue get filed or it will be forgotten, I'm not really working on this problem at the moment and I won't remember to go back and get into it.

-- Scott


--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=CJqEzB1piLOyyvZjb8YUQw&r=YbL7Tj_EqBW9abl6xEy1bg&m=sk8psBzZEl0evvJbJWbHjdouE45uqrN74vb-qeUDW_8&s=g37N2Za6wvgo1EjbvydY2mhtOuX3NWE9uXi2RS5mrv8&e=
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: previous X509 auth result contains subject with no public credentials

Cantor, Scott E.
On 11/23/20, 4:31 PM, "users on behalf of Bobby Lawrence" <[hidden email] on behalf of [hidden email]> wrote:

>    Ok - I will file an RFE with some of the major details of this thread and link to this thread itself....is this the correct link?

It's good enough, I use MARC to find the old messages, it's easy enough once I know what the issue was.

No need to regurgitate anything yourself, you've spent enough time on it. Just a quick summary and a link in the issue is fine. If you want to attach any of the code you used, that might help me think through the best way to tackle it.

Thank you,
-- Scott



--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: previous X509 auth result contains subject with no public credentials

Bobby Lawrence
In reply to this post by Cantor, Scott E.

>>    To make it work, I had to remove the X500Principal and add my
>> UsernamePrincipal on the X509 AuthenticationResult subject
>> directly....before all its principals are added to the new 'merged' subject created by net.shibboleth.idp.authn.impl.FinalizeMultiFactorAuthentication.

> You don't have to remove anything, it's the addition of the UsernamePrincipal that allows the "simple" method to work. The X500Principal won't > hurt anything. Flows just silently skip themselves if they can't understand the Subject's contents.


Just an FYI - I tried this without removing the X500Principal and it didn't work.  I think because I reverted the " shibboleth.PostLoginSubjectCanonicalizationFlows" list back to the distribution where c14n/x500 comes before c14n/simple and since the x500 principal was there, the canonicalization process stopped after setting that the x500 principal name.  So I guess to make this work, I would have to either remove the existing X500Principal like I originally was, or make the c14n/simple flow execute first.

Also - JIRA issue created.  I hope its sufficient.
https://issues.shibboleth.net/jira/browse/IDP-1716


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: previous X509 auth result contains subject with no public credentials

Cantor, Scott E.
On 11/23/20, 5:47 PM, "users on behalf of Bobby Lawrence" <[hidden email] on behalf of [hidden email]> wrote:

>    Just an FYI - I tried this without removing the X500Principal and it didn't work.  I think because I reverted the "
> shibboleth.PostLoginSubjectCanonicalizationFlows" list back to the distribution where c14n/x500 comes before
> c14n/simple and since the x500 principal was there, the canonicalization process stopped after setting that the x500
> principal name.  So I guess to make this work, I would have to either remove the existing X500Principal like I originally
> was, or make the c14n/simple flow execute first.

I didn't recall that that class looked at an X500Principal, I thought it bailed if the certificate was missing. That would be a problem. All the more reason to chew on it a bit before I rush into any fixes.

>    Also - JIRA issue created.  I hope its sufficient.

Yes, thank you.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: previous X509 auth result contains subject with no public credentials

Bobby Lawrence

> I didn't recall that that class looked at an X500Principal, I thought it bailed if the certificate was missing. That would be a problem. All the more
>  reason to chew on it a bit before I rush into any fixes.

It does...at least in 3.4.7
Per the "doPreExecute" method in net.shibboleth.idp.authn.impl.X500SubjectCanonicalization


final Set<X509Certificate> certificates = c14nContext.getSubject().getPublicCredentials(X509Certificate.class);
if (certificates != null && certificates.size() == 1) {
        certificate = certificates.iterator().next();
        x500Principal = certificate.getSubjectX500Principal();
} else {
        final Set<X500Principal> principals = c14nContext.getSubject().getPrincipals(X500Principal.class);
        if (principals != null && principals.size() == 1) {
            x500Principal = principals.iterator().next();
        }
}
       
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]