|
Actions:
|
2021-07-05 08:41 AEST by Arthur Barrett - occasionally we've been asked about openid connect authentication (sometimes called OAuth - though that is
a larger spec).
Now we are using openid connect in the customer downloads app and the online store, we have some more
experience of this.
The login is a slow process which requires a web browser - a url is opened with some parameters and if
successful authentication is made the identity server opens a web page (callback url).
we've previously rejected this for CVSNT because that is just to slow and cumbersome to do for each time
CVSNT connects to the server.
However, by default, the identity server authenticates the client for quite some time - maybe 24 hours (we've
set ours much lower, but still not so low that we couldn't do a large checkin and checkout and still have time
to spare).
So in theory 'cvsagent' could do all this and then store the token from the identity server and reuse if for
subsequent connections.
This enhancement is therefore windows-only, because it will require cvsagent.
The callback url is difficult, because it requires the identity server be able to call the client.
In an enterprise this is usually OK, because the devices will all be internal. But still, we'll need to nominate a
port for this callback, and it is very very unlikely that port will be open by default. Still, if a customer wants to
use this authentication method, they will surely understand the need for a callback url and an open port on
the client.
The alternative would be to do the authentication on the server, which would only require the server have an
open port for the callback.
Could the listeners on port 2401 be smart enough to detect an HTTP (or more likely HTTPS) connection and
handle it smartly?
In this case we would need a new client/server protocol which could encapsulate this authentication - allow
the server to pass the HTTP/HTTPS directly back to/from the client. The client would still be required to
maintain the tokenid etc.
This new protocol would obviate the need for a port to be open on the client, because the client would initiate
the connection to the server and wait for a reply, and the server would send the reply. This will require the
server to match the asynchronous callback from the identity server to the waiting CVSNT/CVSAGENT client -
but that is easy to do with nonce and state
A further more complex approach would be for the high performance server service to store the tokens for
each client and convert the HTTP(S) HTML into text requests for the client, including:
user/email;
password;
OTP;
etc.
I think that would have a lot of problems (what about USB keys?) and maintaining the security of those tokens
per client, across separate sessions - nothing in the CVSNT architecture currently comes close - eg: cvslockd
only maintains locks for the scope of the session. |