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

[Jaime Frey <jfrey@xxxxxxxxxxx>]

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/