There are several ways to authenticate your API requests.įor one, you could use your normal admin user login data to get a token. Obviously, access to the API, same as the GUI, is secured and only allowed for authorized requests. Note: This is only for advanced users and is unsupported by VMware. Just check functions inside the UI and use the network tab to learn about the API endpoint, the HTTP verb used, header information like Accept and Content-Type, and the format of the data required in the request body. Those APIs are not documented, but you can glean their usage by leveraging the Web Developer tools of your browser.
Examples of that can be found on, the Identity Manager Migration/Backup Tool, or the Workspace ONE Access Migration Tool to migrate configurations between test and production environments. As I mentioned, most of Workspace ONE Access is API-based, so more could be done like bulk operations. So those are the documented and supported APIs.
#Lets git it started how to
For example, this code to move federated applications from Okta to Access or this sample showcasing how to use the API from PowerShell. The website has a section that holds some sample code for all VMware products and Workspace ONE Access. All supported Workspace ONE Access API endpoints are documented in the VMware Identity Manager API section. The best resource for all our supported API and related information is, which houses the documentation for all our VMware products. That subset is concerned mostly with user management using System for Cross-domain Identity Management (SCIM), management of OAuth and OIDC tokens, a reports endpoint to retrieve auditing information around authentication, application access, and provisioning, as well as entitlement management. It should be a DevOps dream, but only a subset is documented and supported. Workspace ONE Access is mostly API-driven, so nearly everything you see and do in the user interface is a REST API. Take note of Integrating Client Credentials app with OAuth2, which is also the main way to authenticate with Access APIs for administrators or DevOps. Again on GitHub, we have a wiki that helps you explore the different authentication flows and how they fit certain application scenarios. This toolkit hosts Java SDK sample code for the authentication flow, either as SP (Service Provider) or IDP with Access acting as SP.Ī more modern approach is using OpenID Connect to authenticate and authorize users, as it works better on native mobile applications. Finding the right developer resourcesįor developers keen to incorporate SSO into their apps, you can either use existing frameworks based on SAML/OAuth, or have a look into our sample vidm-saml-toolkit. That is, developers trying to integrate their apps for SSO by either using SAML or OIDC, and administrators trying to automate tasks around auditing and user management. There are mostly 2 personas interacting on the API level. The Hub Services/Notification part will be covered in a later blog post, but for now, let’s delve into what can be done with Access itself. If you are new to the product, you can find more details about Workspace ONE (WS1) Access at:
Access is all about user identities and access to resources, be it SSO into web applications with SAML and OIDC, or providing an intuitive user portal with Hub Services for a combined catalog, people search, and actionable notifications. Welcome back, Devs! Today we take a look at Workspace ONE Access and where you most likely interact with it.
0 kommentar(er)
