We currently maintain a shared quota for all users (students, faculty, researchers-- excluding labs with separate funding for their own Planet licenses) and have to try to equitably divide the quota for everyone on campus. Some of our students want to rely on Planet data for their thesis, some researchers hope to download millions of square km with regularity for their research. To try to ensure that a handful of users don’t consume our entire annual quota quickly, we’ve worked with Planet to designate each unique campus user as their own sub-org.
Our Planet rep is stellar and has been very helpful in this process, but it does mean that users must reach out to us every time they need a quota increase, and we then need to contact the Planet rep to execute the quota increase. It can be tedious, and it would be very helpful to integrate single sign-on for campus users so we can easily control their download quota and adjust accordingly.
The lack of SSO is an issue for private industry as well. Many large companies are beginning to require SSO for external services which may cause concerns with security audits when it comes to utilizing Planet imagery services in the near future.
SSO and user level usage caps are probably the two biggest asks from our org, in terms of administrative infrastructure from Planet. E&R/University accounts are subject to a highly transient population of users, with students, staff and faculty often leaving the university on a 4-5 year cadence. This creates a serious security, and access issue, in that while our University IT departments are quite diligent in disabling email accounts, users maintain access to Planet (and, frankly many other vendors’ products and we’re having these conversations with them too) as long as they reset their passwords in the Planet platform. SSO solves this by offloading the verification of access rights to the user institution. Additionally, E&R accounts have thousands of potential users, per org, and it is cumbersome to manage access at that scale using hand-minted sub-orgs to meter individual use.
When Esri first rolled out the credit-based ArcGIS Online platform, University administrators were hesitant to make it ubiquitously available to their users because there were no “rails” to keep a single user from blowing out all the org credits and interrupting access for everyone. And this is no straw man, either. It happened at Yale when a researcher decided to geocode million’s of addresses, and was able to do so until they had finally burned through all of Yale’s org credits. Essentially, we were in a catch-22, where we couldn’t guarantee access to everyone, if we gave access to everyone. To their credit, the Esri HigherEd team is one of the best customer advocate teams I’ve ever worked with. They listen to their customers, and they advocate for quick implementations. They solicited feedback from administrators on what would make them comfortable opening up access to the platform, and when Esri implemented SSO and default individual credit quotas, those concerns became moot. New users can instantly access resources because identity verification is left to the University SSO infrastructure (we are VERY good at identity & access management, in academia), and those new users have a default quota of credits that they can spend in any way they want. This has made administration of ArcGIS online much less cumbersome (completely hands-off, in fact), and allows us to focus on more productive support for our users, like training. Before SSO and Credit Caps my ArcGIS Online org had fewer than 100 users. Now, I have 3700 users, and those 3700 users require far less intervention from my administrative team, than any other platform we license and support, here.
For us, SSO and default individual credit caps are an obvious duet, with advantages for Planet and Universities, alike. The addition of these features allows us to stop “gatekeeping” Planet resources, providing more time for promoting and supporting Planet data products, internally (I need ROI on my subscription $$, too!). For Planet, they better protect assets from unauthorized access, and encourage administrators to have a more open access policy for these resources, increasing the amount of Planet-based research and novel applications coming out of universities. Win Win.
One last note: Am I seeing correctly that vanilla users are unable to reset their own API Keys? I don’t think I ever realized that, since I (org admin) can reset mine all day long. I was teaching a wildfire workshop last Friday, and we could not find a way to reset user API keys, except for me to do it as the admin. Resetting API Keys periodically is standard practice for us, so that’s obviously another big ask unless I’m just not seeing where to do it. All users who have access to an API Key, should have the ability to secure that API Key. Period.
University administrators have thousands of potential users, and I can’t really think of a relatively safer, better way to stress test your administrative infrastructure (sure, I know it’s not the glittery part, but what is that’s crucial?) than in a university setting where everything has to scale, and be hardened against misuse at scale, even when it’s from very earnest young researchers, just trying to test their limits. If you want to commoditize your platforms, give them to Universities. We’ll immediately show you where the bottlenecks and friction points for access and security are.
In F,L&T,
Stace Maples - Stanford Geospatial Center
More here: https://medium.com/@stacey.maples/why-your-mapping-and-data-platform-should-cater-to-university-research-and-teaching-cd8768c9e7b6
Totally with Stace Maples points from Stanford. What really drove home to me was the this prime example: “Before SSO and Credit Caps my ArcGIS Online org had fewer than 100 users. Now, I have 3700 users, and those 3700 users require far less intervention from my administrative team, than any other platform we license and support, here.”
Like Stanford, ASU has a massive student population and as an org admin, we have a burdensome form process that takes time to complete and verify. SSO solves any verification issues and will accurately keep expired users off our data allotments. We have access to thousands of students (145K in-person and online) along with hundreds of thousands of active learners in the ASU systems. I would love to come back to the forum and ask what do we do when we crush our user limit after the 15K freshman join ASU in the fall and all create accounts. SSO would bring enable the scaling we do very well here at ASU.
I'm one of the administrators for the University of Toronto's Planet.com subscription, which has an active userbase mostly consisting of students. I strongly support the introduction of Single Sign-On (SSO) capabilities.
As other commenters (particularly those working in higher ed) have described, implementing SSO would streamline our large, transient userbase's access to Planet, and will enable us to use the platform effectively long-term. SSO integration is not just a convenience; it’s a crucial step in ensuring that students can focus on their research and learning without the interruption of login issues or the security concerns of managing multiple credentials. The addition of SSO would be a very welcome feature for us, and I can't help but think this would be the case for many other organizations as well.
I’m all for SSO, but how would that eliminate needing to go in and increase someone’s quota if they hit it?
As for an argument for it: a bunch of people sign up and then never use it. So in my opinion, even the minimal barrier to use causes some people to walk away.
I imagine that person filling out our request form on a Saturday morning and already having moved on by the time we give them access at 10am on Monday.
I’m all for SSO, but how would that eliminate needing to go in and increase someone’s quota if they hit it?
As for an argument for it: a bunch of people sign up and then never use it. So in my opinion, even the minimal barrier to use causes some people to walk away.
I imagine that person filling out our request form on a Saturday morning and already having moved on by the time we give them access at 10am on Monday.
I didn’t mean that increasing quotas manually would be eliminated, just that our current method of quota control relies on us receiving a request, reaching out to our Planet rep, waiting for them to review / act, and then following up with the student to let them know their quota increase is complete. We previously had the ability to directly manage quotas for individual users ourselves, which was a significantly faster process and was less work on our end and on Planet’s end. You’re right that it’s a barrier regardless!