Given that you have a federation, could not the federation issue the
signed software-statement to each of the relying parties (existing or
old) and the AS will trust the dynamic client registration if and only
if the signed software-statement is signed by the federation. This fits
more closely with the trust framework model.
Thanks,
George
On 6/1/18 9:57 AM, Matt Pryor - UKRI STFC wrote:
Hi,
I am working on a use case of OAuth 2.0 in a federation and am after some
advice about bootstrapping trust.
Each site in the federation has an OAuth 2.0 authorization server and an OAuth
2.0 relying party. The relying party at each site needs to be registered with
all the authorization servers in the federation. We want to automate as much of
this process as possible, but restrict client registration to trusted members
of the federation. We also want to make onboarding a new federation member as
easy as possible.
This seems an ideal use case for the Dynamic Client Registration Protocol (RFC
7591). The RFC permits the client registration endpoint to require a
pre-existing token in order to register a new client which gives us our
security (only trusted federation members can register a client).
The challenge seems to be in bootstrapping the initial trust. It seems
cumbersome to require that a new federation member must manually obtain a token
from each authorization server before registering - they may as well manually
register their client. I'd be interested to know if anyone has any ideas for a
solution other than securely distributing a shared secret to new federation
members.
One possible option is to piggy-back on the legacy authn/z we already have -
users can obtain an X509 certificate from their home idp, which is then trusted
by all the other sites. We can then obtain SAML assertions about their
permissions based on that certificate. We could use this mechanism to maintain
a list of trusted admins, requiring authentication with an X509 certificate
with the correct SAML assertion for the client registration endpoint. However,
we are hoping to retire the X509 support in the short-to-medium term, so I'm
also looking for solutions that do not use it. I'm also not sure how the use of
X509 certificates would fit in with an RFC-compliant implementation of the
Dynamic Client Registration Protocol.
Thanks in advance for your help,
Matt
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
