Open sserrata opened 5 years ago
Hey @sserrata,
I think this would be good, as I've read this could be a really big change for any applications using the get_authorization_url
method to derive the auth_base_url
and state
, meaning a state parameter is not provided by user, but would give us better populated dynamic groups.
Description
There are two scenarios where the concept of
region
is relevant:region
extracted from the base64params
provided by the Cortex Hub redirect which is used by theget_authorization_url()
method, e.g.americas
oreurope
.api.us.paloaltonetworks.com
orapi.eu.paloaltonetworks.com
(currently defaults tous
).The first is relevant to the identity provider while performing authorization whereas the second determines what regional datacenter to direct API requests to (which should correspond to where the
Cortex
data lake tenant, et al. reside).Currently,
pancloud
is missing a way to set or define a defaultregion
that could be used to determine which regional datacenter to direct API requests to. With the current API, you're forced to supply the full API gatewayurl
to direct API requests to a region other thanapi.us.paloaltonetworks.com
, which is the default.Proposals
1) Add a
default_region
kwarg to theHTTPClient
class. The value provided, e.g.us
oreu
, could be used to construct the defaulturl
used in all API requests made with thatHTTPClient()
object. Note thatdefault_region
would not be applicable to theCredentials
class. 2) Add support for aPAN_DEFAULT_REGION
environment variable. The behavior would be similar to proposal1
except that thedefault_region
constructor argument would take precedence over the envar. 3) Add support for adefault_region
orregion
to thecredentials.json
file or credentials store. This one feels a bit out of place, since the region would not necessarily be applicable toCredentials
. Again, theregion
used byget_authorization_url()
should normally be extracted from the base64params
passed by the Cortex Hub. It's worth noting that AWSboto3
credentials allow for specifyingregion
. Note that thePAN_DEFAULT_REGION
envar would take precedence over this value.Other considerations
Another interesting approach would be to leverage a custom JWT claim to determine the regional URL, since the IdP would ostensibly have prior knowledge of the
region
used during authorization. The challenge with such an approach would be sharing theregion
across multiple instances ofHTTPClient()
since the value would, ostensibly, be extracted from theaccess_token
in thefetch_tokens()
orrefresh()
response (an operation performed within the scope of a singleCredentials()
object).Another thing to note is that it is quite easy for an app to implement its own "region selector," since an application would also have knowledge of what
region
was used during authorization. This is the current recommended way to handle regional selection ofurl
in the absence of default region support.