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/