1. Proposed title of this feature request
Conditional access to OpenShift based on its origin of request coming to Openshift API
3. What is the nature and description of the request?
we would dynamically provision access rights to OpenShift when a user logs in and an OAuth token is issued. Depending on the users origin, access right would be provisioned conditionally. Also, a mechanism would need to make sure that as long as a user is logged in with a specific token, that token is associated with the users "origin" (so that he/she cannot switch from internal to external access with the same token).
4. Why does the customer need this? (List the business requirements here)
Because we use one OpenShift instance for multiple tenants, we have the requirements to treat access to the OpenShift API "conditionally". If a user comes from the internet, he might have access to only a subset of projects. If he accesses the API from trusted networks or devices, he shall have access to all projects. The motivation is to prevent data leakage for some projects (but it should be our tenant's choice for which projects this rule should apply).
I think the solution for this is to use a frontend authentication service like keycloak, and let it add proper groups to the user identity based on whatever rules are established there for access.
This will allow to access some role automatically once this  PR (and some more support code) is implemented.
Just to be clear, there is no plan to implement complex logic that looks outwards from our database to determine access. An external IdP will be required to do what is requested by the customer. The details of how the customer filters access will be dealt with in the IdP.
An IdP cannot solve this requirement though. An IdP is only consulted at authentication time; but the problem appears later, after OpenShift has issued a OAuth token to the user: It must not be possible for that user to copy that token to another device, and access OpenShift from there.
OAuth is a bearer token system, there is no way to bind the token to a device.
Well, we are not asking for it to be resolved through OAuth alone; just one way to "bind" to token to a device is to store the users IP (e.g. in Etcd), at the time when the token is issued, and check, on subsequent calls, that the user still has that IP. Most certainly you could come up with more sophisticated ideas ...
That wouldn't work as tokens are transmitted and sometimes there are proxies or other hand offs that would not allow to check IP addresses. Even the initial auth itself may not be able to easily determine a client IP address, depending on network configuration.
Embedding IP addresses in tickets has been done before, in kerberos, and had to be subsequently abandoned as it created a lot more problems than it solved.
I am not saying there is no way at all to come up with some way to try to restrict some of this, I am just setting up expectations, we do not see a near term solution along the lines you are requesting.
It may be easier to monitor and take remedial action (like disabling accounts) by using an external system that correlates logs.
Thanks, I see that even if it might work in our case, it would be probably impossible to generalize ...
After additional consideration we determined we cannot implement this RFE, so closing.