External Identity Provider: add design for idplink API

[abbra]

Could you please add a note that 'client_id' is a secret, thus should probably be handled similar to a password, e.g. asked separately and not specified on the command line. This also means an example needs to change.

Once you fix it, we can merge the design and update OIDs when actual implementation would be done.

The Tox failure will be fixed with a rebase onto a new upstream later.

[flo-renaud]

Could you please add a note that 'client_id' is a secret, thus should probably be handled similar to a password, e.g. asked separately and not specified on the command line. This also means an example needs to change.

I am not sure about that, since the description in rfc 6749 clearly states the following: "The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication."

Once you fix it, we can merge the design and update OIDs when actual implementation would be done.

The Tox failure will be fixed with a rebase onto a new upstream later.

I haven't consider yet the indices that should be added to 389ds, or the WebUI requirements. I will soon update the design proposal with this information.

[abbra]

ok, makes sense. Thanks for explanation.

[abbra]

I added few comments. Please allocate OIDs and update them in the document, then we can merge this.

[abbra]

I think we can assume that subid PR would get in before us. In practice, it does not matter because we simply have to allocate the OIDs in RHANANA and that is enough. I'll ask Christian whether subid schema is final.

As for the rest, yes, may be just use 'idp' instead of 'idplink' for the object name is enough. We can add 'External IdP' title to menu items and documentation.

[abbra]

Merged, thanks.