Hi - I'm trying to answer a question about non-repudiation in API calls.
If the service can get the identity for an OpenZiti connection, this would probably be enough.
I've searched and can't find anything relevant.
Presumably the connection identity is available from somewhere, but can it be accessed from the API service?
I suspect I would need to modify the API to use the OpenZiti APK, or a create a custom end-point to append the connection identity to the data, but that should be OK.
Hi @duncan.simey, welcome to the community and to OpenZiti (and zrok/BrowZer)!
I'm not exactly sure what you mean. Which one is 'the service'? I believe you are referring to the process that is accepting an incoming connection, if that's not correct please do correct me. If you have an OpenZiti client using an SDK and you have an OpenZiti server using an SDK, the server can inspect the incoming connection, yes. In the go sdk, the "SourceIdentifier" would be usable to determine the identity making the connection to the server. If you'd like to try an example, the chat p2p example would demo it for you: sdk-golang/example/chat-p2p/chat-p2p.go at 0b341d7d7dbb1ec8968960d3c5d3f4f3e3fa460d · openziti/sdk-golang · GitHub
Hey that's perfect!
Yes, I meant the process that is accepting an incoming connections. OpenZiti terminology is still new to me, sorry.
Assuming a JWT is used to authenticate API calls, that tells us WHO. But being able to log WHERE would be a valuable addition. OpenZiti end-point enrolment gives us an identity unique to the WHERE. Perfect!
FYI - I'm researching how to improve API security to ease compliance with cybersecurity legislation. OpenZiti is looking like an extremely valuable tool.
No worries! It's incredibly easy to use an overloaded term and confuse one side or the other, so thanks for bearing with me. I just want to make sure I answer the proper questions.
Glad to hear this covers what you were looking for and happy to hear things are looking promising!
Cheers!
1 Like