Re: [HTCondor-users] idtoken authorisation and hostnames in fully qualified user strings

[Andrew Pickford <andrewp@xxxxxxxxx>]

    Hi Jaime,
      
      Version 24.3.0 fixes the problem. I do now get the expected
      authorization failures when the hostname part of the fully qualified user string is not a match to the machine requesting authorization even when the idtoken name and domain parts of the fully qualified user string are a match. Authorization now only happens when all three parts of the fully qualified user string are a match. I have not fully tested wildcard matching but simple wildcards succeed and fail as I'd expect from the documentation.
    

Thanks,

Andrew

On 08/01/2025 16:37, Jaime Frey via HTCondor-users wrote:

> Can you retry with the just-released HTCondor 24.3.0? 
>
>  - Jaime
>
> > On Jan 7, 2025, at 8:11âAM, Andrew Pickford <andrewp@xxxxxxxxx> wrote:
> >
> > Hi Jaime,
> >
> > Thanks for taking a look at this. It will be nice to know if this happens for someone else or if I've somehow got a broken config.
> >
> >
> > Cheers,
> >
> > Andrew
> >
> >
> > On 18/12/2024 23:15, Jaime Frey via HTCondor-users wrote:
> > > That is surprising. Iâm looking into it.
> > >
> > >  - Jaime
> > >
> > > > On Dec 16, 2024, at 9:57âAM, Andrew Pickford <andrewp@xxxxxxxxx> wrote:
> > > >
> > > > Dear All,
> > > >
> > > > I was doing some testing of idtoken authorisation and found that the ALLOW_* configuration settings did not honor the hostname part of the fully qualified user string. This is on htcondor 24.2.2. So for example with:
> > > >
> > > > SEC_DAEMON_AUTHENTICATION = REQUIRED
> > > > SEC_DAEMON_INTEGRITY = REQUIRED
> > > > SEC_DAEMON_AUTHENTICATION_METHODS = IDTOKENS
> > > > ALLOW_DAEMON = condor_idt@dev-local-ndpf/vaars-11.nikhef.nl
> > > >
> > > > and using the idtoken condor_idt@dev-local-npdf, then 'condor_ping -addr "<145.107.4.2:9618>" DAEMON' does a successful authorisation as expected from the machine vaars-11 but also succeeds when done from a different machine. As a double check I've changed the ALLOW_DAEMON idtoken string to things like 'wrong_token@dev-local-ndpf/vaars-11.nikhef.nl' and got failures to authenticate as expected.
> > > >
> > > > Looking at the documentation with the above ALLOW_DAEMON configuration I thought that the use of the idtoken 'condor_idt@dev-local-ndpf' would be only allowed if coming from vaars-11.nikhef.nl. I correct here? That with this configuration the idtoken should be rejected from machines other than vaars-11, or have I missunderstood this part of authorisation? Or maybe condor_ping is not doing the authorisation tests I think it is? Or is this a different but expected behaviour for authorisation when using idtokens? Or something else..?
> > > >
> > > >
> > > > Cheers,
> > > >
> > > > Andrew
> > > > _______________________________________________
> > > > HTCondor-users mailing list
> > > > To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> > > > subject: Unsubscribe
> > > >
> > > > The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/
> > > >           
> > > _______________________________________________
> > > HTCondor-users mailing list
> > > To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> > > subject: Unsubscribe
> > >
> > > The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/
> > >         
> > _______________________________________________
> > HTCondor-users mailing list
> > To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> > subject: Unsubscribe
> >
> > The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/
> >       
>
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
>
> The archives can be found at: https://www-auth.cs.wisc.edu/lists/htcondor-users/
>