Directory access stopped working

Tenley Peterson

A couple years ago, we worked with a developer (Sheamus) to make an app so our community could access our directory from their smart devices. It worked fine until a few days ago. Users can no longer get in.


The way the app is set up is that we created a dedicated portal user and role for the API. This role has directory access, and that was sufficient for allowing this portal user to fetch the data for the app. What we believe happened is Blackbaud changed their default access to OnAPI endpoints, so our portal user has lost the ability to get the data that it needs to be able to fetch.


Does anyone know if Blackbaud recently changed their security/access settings or which permissions allow an account to fetch API data? Anyone else having this problem?


EDIT: While the `user/all` endpoint stopped working for this particular user, other endpoints such as `user/{user_id}` continue to work for authorized user_ids.


We did not set the user up with the Web Services role, but instead gave them directory access through the `People Finder` task permission, which granted them the proper authorizations they needed to access endpoints like `/users/all`. On November 25 things stopped.


 

Steven Cinquegrana

Just a guess, and I don't personally know of any changes to ON, but we've seen other API access - from various vendors - fail out-of-the-blue when TLS 1.0 has been turned off but the consuming app is not yet set up to use TLS 1.1/1.2.


I'd maybe start there. At least check that your app is using TLS 1.1 and/or 1.2 and definitely not using TLS 1.0.


Of course, it could be nothing whatsoever to do with that! Please post back when you find the cause.


Cheers,

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


PS If you have any error information to share it might be helpful.

 

Tenley Peterson

Thank you for this idea. I will look into it. 


Here's the error pop up we're getting.

Steven Cinquegrana

There's not really much to go on there other than it's likely that some variable hasn't been assigned properly, leading to a null object error deeper down. (Just a guess.) You'll need to run diagnostics on the app at a debug level I'd say. Hopefully your developer is still on hand to do that.


Have you explicitly asked Blackbaud about any ON API changes, TLS or otherwise?

 

Tenley Peterson

Thank you for your help! Developer is on hand still, fortunately. I'm assisting him by posting here.


I posted a question in the Blackbaud Support tool asking about recent API changes and for any release notes. Knock on wood the info comes back soon.

Janet Wittenberg

Hi Tenley,

What security authentication, if any, happens with your directory app?  In a recent security review we did further restrict access to some of our endpoints, but didn't intend to cause unexpected behavior. You need to guard that data with some access and permissions.  If you are already relying on login and access, please open a case with support so can make sure that data is available to the right people. 

Janet

Sheamus Burns

HI Janet Wittenberg‍ and Tenley Peterson‍ 


Janet, I'm the engineer working with Tenley to maintain a project that depends heavily on the onApi (and cannot migrate to SKY because our users are not migrated to BlackbaudID).  We would love to discuss what endpoint access has changed and what conditions qualify that a user with previous access to an endpoint no longer has access. This is certainly the issue we are running into, and would welcome moving this to a private conversation, or possibly a call to discuss.


While I certainly understand the need for security audits around customer facing apis, I have to admit that I find it frustrating when customers are not given advance warning of breaking changes that potentially impact (and I assume have impacted in our case) mission-critical custom applications.


We've tried to re-build one application, but are still failing to achieving the same end results that we were easily able to accomplish before the endpoint access changed. I suspect if we understand better what changes were made, it can help us to determine if there is any way to achieve the same functionality with what is currently available. 


The endpoints we are using, for which we're now seeing Authorization Error codes, but previously were getting 200 statuses are:


using a non web-services-api user that had the `People Finder` task permission on their role

`/user/all` (this was previously not accessible by all users, but by some with specific roles in the system)


using authenticated user's token, accessing the data of other users (where the data is for a user who is not the authenticated user):

`/user/address` (afaik this never threw a 403 for any user, but now it does for some)

`/user/phone/all` (afaik this never threw a 403 for any user, but now it does for some)

`/user/occupation` (afaik this never threw a 403 for any user, but now it does for some)


We can discuss the authorization practices the app employs, but in essence we were previously able to:

1. authenticate a user in the system (we can still do that),


2. show them a list of all users (we now use a web api services account token for that on the server side and can still do that),


3. using the authenticated user's token, fetch `user/{user_id}` for the user we want to show information about (we can still do that, but the endpoint only returns a minimal amount of information, which is why we needed to use the supplemental user endpoints above in the following step)
Just a side note about this endpoint: originally when we first were developing the app in 2017 we could use the authenticated user's token to fetch the `user extended` endpoint, but we pointed out to the API team that the additional information that endpoint returned included data that should be restricted by the Profile Publish Access feature, and instead of fixing that endpoint to return only the data users should be able to access, the API team completely restricted access to that endpoint to only users with the Web Services role, which I thought at the time was the wrong decision, because it forced the authenticated user to make additional calls to the 3 user specific endpoints (which we're now suddenly experiencing restricted access to) to get all the data they "should be able to see" because of Profile Publish Access.


4. use the authenticated user's token to fetch directory data for other users in the system using the 3 endpoints above. It seems in some cases that no longer works (but I'm not sure what the conditions are for the users for whom it doesn't work),

The reason using those endpoints was essential for our application: the only way to get back directory data that applies the restrictions put on user profile data via the `Profile Publish Access` feature was to call those endpoints for another user using the authenticated user's token. 


I'd appreciate the opportunity to discuss this further, so we can try to work out what gaps remain due to the security changes and what are the best steps forward.


Thanks,

Sheamus


 

Janet Wittenberg

Sheamus,

Absolutely. I will set up a call this week.  Thanks for providing all the detail ahead of time so we can be prepared. 

Janet