SSO major editing

[Paul Harrison]

Hi All,

Taking Mark’s suggestion of perhaps stepping back and thinking what SSO actually means might be useful. 

From a user’s perspective it means only having to provide identity credentials once to access a number of different services within a particular realm - the greater the reach of the realm the more useful the “SSO”. At the time that the original SSO specification was written it seemed that X509 user certificates were a great option - the user only had to obtain a single certificate that could be useable everywhere - from the software client point of view it was also simple - via a relatively small number of pre-defined certificate authorities it was possible to confirm that a certificate was trustworthy. However the widespread use of user certificates did not really ever become commonplace (I still renew my annual e-science certificate - this message is signed with it - however I am in a minority).

The reasons for the lack of take-up of X509 certificates probably are because of the costs associated with providing the service of identity management and perhaps more importantly revocation of “invalid/stolen” certificates. In addition the user experience of having to apply for and manage their copy of their certificate was also a barrier to adoption.

There is a significant commitment of the SSO service provider in managing the identities.  This one of the reasons that “bearer token” style SSO systems have become more popular - the tokens have short lifetimes, so that the damage that can done with stolen tokens is at least limited to a short window and nothing special has to be done to “revoke” the token. These systems are not as secure as the X509 PKI, but have many of the same security properties as X509 proxy certificates do.

The SSO_next document uses IVOA specific authentication schemes for “bootstrapping” the discovery of the URL to which authentication credentials should be passed. However, to me, it seems that if there were true SSO for the VO then there would probably only really need to be a small number of SSO servers (often called proxies in AAI literature) that could be “well-known” to clients in much the same way as registries are. An open source example of such an SSO server is https://www.keycloak.org/ and then the clients just talk standard OIDC or SAML, and it is the SSO server that is connected to the identity provider.

I think that the non-browser client issue is still not completely solved by this approach if the user is “unaware” that they need to log-in, but there are some interesting approaches e.g. https://github.com/indigo-dc/oidc-agent if they are.

Regards,
	Paul.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20240513/d8b00ec6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20240513/d8b00ec6/attachment.p7s>