Keycloak Admin Deployment Requirements

• As a SaaS on the Internet
• As a Saas on a company Intranet
• Support deployment of the SaaS Admin login/registration/ui on a different server than the Token Service/application login/register/oauth. This will be useful if you want to put the admin UI/REST services behind a firewall and keep the Token Service available to a wider group of clients.
• Support the admin REST interfaces executable in a CORS environment
• Support the admin UI panels as Uberfire portlets that can be embedded in server apps that don't run on the same server as admin REST interfaces.
• Support a CLI that invokes on admin REST interfaces
• Support a programmatic admin API

If the admin UI and admin REST interfaces are not under the same domain name, then you're going to have to require CORS which opens additional security risks and browser support issues?

I can definitely see that you'd want to deploy the Token Service (and SSO login/OAuth grant pages) on a separate machine than the admin. But, IMO, the admin UI and admin REST interfaces should reside under the same logical domain name.

• In the not so distant future the admin console has to be split into UberFire panels, which can then be reused. For example the console for a MBaaS/IPaaS product may want to embed the Keycloak console. In this case it is highly likely that the console won't be deployed to the same server

I think this point may be irrelevant. An MBaaS/IPaaS falls into the remote application catagory So the MBaaS/IPaaS would use the OAuth login to Keycloak. Then, any REST calls made to the Keycoak Admin REST interface by the MBaaS/IPaaS browser app will have the necessary cookies all set up. CORS should be handled by the browser, correct?

• Mobile/web bundled app
• CLI
• Programmatically

Right now, the admin REST interfaces can be authenticated with either a cookie or a bearer token. So the admin REST interfaces already support all the use cases you list above.

For the admin UI itself, if we don't hardcode the URLs, it doesn't care where the REST servers live. CORS is all handled by the Browser and servers involved correct? There's nothing that needs to be done in Javascript, right?