Hi,
In earlier days there was a clear 1-to-1 relationship between a connect app and an app user that was - more or less - treated like a normal user, i.e. you could consciously make decisions about granting or not granting access to spaces or what level of access the user had.
This way a user or organisation could use apps and still make decisions about what data is visible to apps (and even to which app) and what isn’t. Now it seems to me the app users are getting hidden more and more - or work differently maybe?
E.g. my app can read data (space/content) from a space, but isn’t showing up in the space permissions individually. I removed confluence-users from the space, now my app cannot access the data from the space anymore - but at the same time the app isn’t shown as a member in confluence-users.
Is there any documentation on this? Where is this going?
Thanks in advance, Chris
Thanks @dmorrow - I want to emphasize that in the past we have repeatedly been told at events such as app weeks that the Cloud product teams would appreciate apps having rather less Connect scopes than more - but this is impossible if the app user related scopes can not be managed properly (by the user). As a last resort we might have to turn to ACT_AS_USER, where we can advise users to create a user for the app / use case and configure that in the app. BUT effectively an app can act as any user then, which gives a bigger margin for error (and security holes).
Within a particular product instance an administrator may further limit the actions that an app may perform. This is valuable because it allows administrators to safely install apps that they otherwise would not.
@dmorrow We found that the app user isn’t all invisible - although has reduced visibility. But it is named in an unforeseen way. For us it seems that the name is ‘set in stone’ in the way the it was named the first ever installed with the given app key. Can you confirm that?
So in our case we copied the atlassian-connect.json at the beginning of the development efforts and changed the key but didn’t change the name from the copy source and now on every test cloud instance there’s a user named ‘Scroll Documents (Christoffer, Local)’. How can we change the name of that user to match our app?
Thanks
As you’ve probably worked out, there’s no synchronisation process between the app descriptor and the name of the user associated with the app. Changing the name is manual and can only be done by Atlassian’s Identity team. I’ll update our app descriptor documentation to highlight this.
@dmorrow has taken this into his hands for us and driven it to resolution in only two days. Thanks a lot - I am happy not having my name to turn up on our evaluators’ and users’ cloud instances
A short recap on what works how with app users (when you use JWT):
Make sure to get the name of your app correct the first time you ever install the final app key to a cloud instance. At that point in time the name of the app user will be ‘frozen’ wrt. your app key.
The app user is automatically a member of confluence-users (which will give you access to space that are created with the default space permissions)
The app user cannot be added to or removed from groups
The app user can be given specific permissions on a space and can be added to page-level restrictions
The app user continues to exist after the app is uninstalled
To be more precise - it seem that the app user is automatically a member of the ‘Default access group’ (which is confluence-users in a vanilla instance)
It would be great if Atlassian could let us know a bit what their plans are.