Environments & Authorization

Steven Cinquegrana

This is a pretty specific authorization question which I’m tagging @Ben Lambert on but if anyone else has any thoughts, please chime in.

We’re revamping the authorization management of our SKYLib•NET Code Library and SDK and I would like to understand the limits of how Environments can be used in applications.

As background, a while ago SKY API authorization was moved from its original Product scope to Environment scope. For example, The Gift API was originally authorized against the Raiser’s Edge NXT as a Product so the authorizing user needed to have this Product available to them in their Environment. Similarly, the General Ledger API was authorized against the Financial Edge NXT Product, the School API against the Education Management Product, etc. If all three (or more) Products existed in the Environment, separate authorization for each API was required.

With the Environment-level authorization scheme, one authorization covers all Products in an Environment.

(The user still must have been granted access to the Products and their APIs within the Environment; this hasn’t changed.)

NB: I think I have all of that right, but I stand to be corrected if not.

Now, my question is: Would it be conceivable that an instance of application requires access to multiple Environments and therefore must manage individual Environment authorization credentials?

Given the statement in the documentation, “You can think of each environment as a separate isolated container that doesn't typically act on the same data”, I tend to think the answer is No. The main complication would be where two (or more) Environments each contain the same Product(s). I don’t really see how this would be manageable without a lot of code overhead.

The impact on SKYLib is that if we can assume that a given application that utilizes SKYLib will only ever need to authorize for a single Environment, this greatly simplifies authorization handling, reduces Blackbaud server load (fewer authorization calls) and speeds things up (again, due to fewer authorization calls).

Looking forward to some insightful replies.

Cheers and thanks,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

Ben Lambert

Hi Steve,

Your write-up is correct. Authorization is scoped to a Blackbaud environment (which is a container for products/services that a customer may have). Environments represent a boundary of scope for product functionality, so it won't be the case that a customer's product/service in one environment needs to talk to a product/service in another environment for the customer. That'd be a very atypical configuration and not something likely to occur in the wild. Within our UX, the omnibar provides continuity of navigation between services within an environment - switching to a different environment (or a different “organization”) is an explicit change of context.

So one authorization (consent) produces a token for a SKY application (i.e., an OAuth client_) that is attached to the consenting user in the context of the selected environment. That token can be used to call APIs for any of the products/services in the environment (subject to the user's access and permissions within that environment).

Hope that helps!

Steven Cinquegrana

@Ben Lambert Thanks - that helps a lot.

Dan Snyder

@Ben Lambert “Not something likely to occur in the wild”, haha!?