enduser management api

Hi,

        My wishlist as below:

1) Integration with Azure AD SSO

2) Once an AAD account is removed, ideal to be able to automatically remove account holder's access to the Mendix platform if he is an admin or a developer

3) Remove his access to applications developed on Mendix

4) Notify admin of such applications to follow up on any application-specific cleanup, where necessary 

 

Thanks!

Created 2024-07-25

Ser Wee Chia

Hello All,   

 

similar to what Ryan Groeneveld commented, We have audit cycles are our company and a part of those is a review of user's with access to Backups.  We would like to have access through the api to create reports for this to review and documentation.  

Created 2024-06-19

Billy Pecora

Hey @Ryan Groeneveld,

 

Yes I've seen - and actually the fact you are getting your private cloud app in this API is because Mendix have also a Public Mendix Cloud "Free" tier env deployed for you for this app. That is why you have a Technical Contact also. This happens when you use Sprintr web interface to create apps. We do not deploy apps via Sprintr anymore, we use our own CI/CD pipelines and / or Studio Pro, also mendix said they will fix this (status from September).

 

Long story short after struggle with Mendix support conclusion is:

• For real Private Cloud apps you should not have Technical Contact (only used in Public cloud)
• You should NOT see your app on this API you mentioned as it's ONLY for Public Mendix Cloud
• There is NO API to pull all apps from Private Cloud 

 

So my 2nd requirement is not longer valid as per Deploy API v4 released. Nonetheless I would say it will be better to have USER management features in one endpoint/scope.

Created 2024-01-29

Przemyslaw Pazik

Hi Przemyslaw Pazik,

 

For you 2nd requirement, did you have a look at: Deploy API – Version 4 | Mendix Documentation?

 

using https://cloud.home.mendix.com/api/v4/apps returns:

{
  "apps": [
    {
      "id": "c533ee0b-f7db-4e62-868b-1192d392ccec",
      "name": "My fabulous app",
      "licenseType": "free",
      "subdomain": "myfabulousapp",
      "technicalContact": {
        "userId": "jane.doe@domain.tld",
        "name": "Jane Doe",
        "status": "active"
      },
      "region": "prod2-eu-central-1"
    }
  ],
  "pagination": {
    "offset": 60,
    "limit": 20,
    "size": 17
  }
}

Created 2024-01-29

Ryan Groeneveld

In our company, compliancy is really important. We get internally audited periodically.

 

Important part is having the User Management in place, Platform and App wise. Therefor we've created an extension to Control Center to retrieve the users from the environments of the deployed apps, import the members from Control Center and compare this to the state of Active Directory accounts. Once an AD account linked to an app or member account, is disabled or removed, we report on it and take necessary actions.

 

Actually the app can do a lot more, as all relations between entities helps in Life Cycle Management, Container usage for the yearly contract negotiations, ect.

 

All the comments mentioned above have my vote as well.

 

In addition it would be great to retrieve which apps the user is technical contact or member of, licensed and free. This way we can also remove their projects or send out emails to cleanup from a housekeeping perspective. Only AppId and EnvironmentId would be fine, but more is great.

 

Having more of Control Center available as a Company Admin would be really helpful.

 

From the Export to excel in Control Center the following properties are available:

Internal members:

• Email
• Name
• Status
• Certification
• NumberOfApps
• SignupDate
• MendixAdmin
• JobTitle
• Country
• Location
• UUID

LastActivity would be a great addition.

 

External members:

• Email
• Name
• Certification
• NumberOfApps
• Company
• Status

Created 2024-01-29

Ryan Groeneveld

Rank 1 offboarding automation is key.

• ability to deactivate
• ability to reassign apps as tech lead
• ability to delete apps that no longer have value i.e. one made for their training

Rank 2 development stage of user lifecycle

• Know developer certification level, email, date started, # of apps
• ability to change tech lead of app

Rank 3 On boarding

• Ability to create profile
• ability to add picture to profile
• We have some internal steps to have completed as well and creating an interface on our end to simplify the process for them.

 

Created 2024-01-12

Peter Mendez

I agree with Johan, Offboarding process is the most important use case.

 

In our use case it will be also needed to have the capability to search for users by OpenID to get user email address. 

As the current endpoint https://usermanagement.mendix.com/legacy-api/1/users provides list of ALL users in company, identified by OpenID. There is no documented way to get account details like email address for each profile and we are only able to check if employee still has active account by the e-mail address.

So either we will have an email address in the endpoint which get list of all users or a way to query system for profile details (including email) by accounts OpenID.

 

2^nd requirement will be to provide a way to get either list of apps where user is a Technical Contact in this API or in the Deployment API. There is API to Change Technical Contact but there is NO WAY to get who is technical contact for an application via API.

Created 2023-08-25

Przemyslaw Pazik

The most important use-case for us is: offboarding of colleagues.

If somebody leaves our company, the automated offboarding process makes sure that access is properly denied from that moment on by deactivating their Mendix account.

This consists of two steps: check if account on e-mailaddress is created. If so: deactivate this Mendix account. 

Execution of these steps is done using a service account.

Created 2023-08-24

Johan Flikweert