The following endpoint returns a list of available contexts: `GET /compute/contexts`
However, not all of them can actually be used by the end user, as noted:
Only users who are allowed to use the context can create a session. This is governed by the authentication rules that are defined when the context is created.
Is there any way (other than spawning a session on each context) to identify which compute contexts are available to a particular user / client?
Hi @AllanBowe,
I got the following response from a developer:
Each context has a “rules” link that an admin can use to get the authorization rules that apply to POST /compute/contexts/{contextId}/sessions requests. The response you get from executing the “rules” link would show the rules added by the compute service when it created the context to govern who can use it to create a session. The rules would show the users and groups allowed to create sessions with the context, or if all authenticated users are allowed to create sessions with the context (or even if guests are allowed to). If you don’t get back any rules, then only admins can create sessions with the context.
This method is not fool-proof. It is always possible for a site to add a rule that the compute service knows nothing about that would influence authorization on POST /compute/contexts/{contextId}/sessions requests. For example, a site could add a rule denying certain users or groups access to POST /compute/contexts/*/sessions, and that rule would take precedence over any rules added by the compute service. The only way to take that kind of thing into account is to ask the authorization service for an explanation: https://gitlab.sas.com/petrichor/authorization#authorization-explanations.
I hope this helps.
Thanks,
Joe
Join us for SAS Community Trivia
SAS Bowl XLII, SAS Hackathon 2024
Wednesday, August 14, 2024, at 10 a.m. ET | #SASBowl
Hi @AllanBowe,
I got the following response from a developer:
Each context has a “rules” link that an admin can use to get the authorization rules that apply to POST /compute/contexts/{contextId}/sessions requests. The response you get from executing the “rules” link would show the rules added by the compute service when it created the context to govern who can use it to create a session. The rules would show the users and groups allowed to create sessions with the context, or if all authenticated users are allowed to create sessions with the context (or even if guests are allowed to). If you don’t get back any rules, then only admins can create sessions with the context.
This method is not fool-proof. It is always possible for a site to add a rule that the compute service knows nothing about that would influence authorization on POST /compute/contexts/{contextId}/sessions requests. For example, a site could add a rule denying certain users or groups access to POST /compute/contexts/*/sessions, and that rule would take precedence over any rules added by the compute service. The only way to take that kind of thing into account is to ask the authorization service for an explanation: https://gitlab.sas.com/petrichor/authorization#authorization-explanations.
I hope this helps.
Thanks,
Joe
Join us for SAS Community Trivia
SAS Bowl XLII, SAS Hackathon 2024
Wednesday, August 14, 2024, at 10 a.m. ET | #SASBowl
Build your skills. Make connections. Enjoy creative freedom. Maybe change the world. Registration is now open through August 30th. Visit the SAS Hackathon homepage.
Register today!Learn how use the CAT functions in SAS to join values from multiple variables into a single value.
Find more tutorials on the SAS Users YouTube channel.
Select SAS Training centers are offering in-person courses. View upcoming courses for: