How to store user authentication in a Confluence add-on using Atlassian connect

[Lutz Bliska]

I would like to develop a new Confluence add-on using Atlassian connect to publish in Atlassian Marketplace.

The Confluence add-on should be able to store a custom user authentication for authenticate and consume data of a 3rd party software by rest api.

After the user successfully logged in, the add-on should be able to show / list user-specific content of the 3rd party software.

Is this possible and how could i do that ?

Thanks for any advise

[eero · Accepted solution]

Hi,

It looks like there might be some confusion around what Connect is and what you can do with it.

Connect addons are actually standalone applications, deployed on your own application servers. We place no restriction what data they can store or which external systems they can access. Any data can be displayed to end-users in JIRA/Confluence using things like dialogs, pages and web panels.

It would be completely possible to show a dialog to the end user which would authenticate them against a third party system. Ideally the authentication would be using something like OAuth2, in which case your service would not have to store any user credentials (other than access/refresh tokens).

The introduction chapter in our documentation should provide a good overview about what Connect addons are and how you could implement one.

Please let me know if you have any further questions.

Best Regards,

Eero

[Alexander Sopov]

Hello People!

So, from the answers I've gathered here, entity-properties of the kinds that exist would be one place to store the auth-credentials to a third-party software, but they're not entirely safe so there's a need to encrypt it. Also, to make it user-specific, one would use entity-properties of type "user". 

Second, since you're hosting the add-on yourself, the freedom to chose how to store this on the add-on vendor-side is endless. However, I feel like this (somewhat) infringes on the User's integrity.

Sure, most web-apps store the user credentials in some way, but here I feel like that since it's an add-on that "runs" on the customers system, it is only appropriate to store it on "their" end. Especially since the third-party software I'm integrating hosts a lot of IP's, I feel like the end-users would prefer the credentials to be stored on "their" end, rather than ask them to trust us with the access to all of their IP's.

So, I guess my comment here consists of two questions. One, am I right to reason that end-users prefer to keep their authorization-credentials to themselves? And two, @Lutz Bliska, did you get it working with the crypto module and would you like to share how you implemented it?

Best regards,

 - Alexander S 

[Lutz Bliska]

Hello @Alexender

As far i know the entity-properties are only available for jira-software and not for confluence.

The implementiation is simple. Just encrpyt the form-data from the login-post request and store them in the database-table e.g. User.

We used a postgres-database for our production environment and create a db-model like that: 

1. Confluence-Instance - Table

(It's a clone of the Instance-Table who is created during the install process of the the add-on,, but we would like to have it under our control)

2. Atlassian-User - Table 

(Contains the association between Instance and Atlassian-User)

3. Add-on User -  Table 

(Contains the association between Atlassian-User and Add-on-User)

The hardest point will be the session-management (we use module: connect-redis), because the add-on run in it's own iframe and will be handled from a browser as a 3rd party cookie and e.g. safari don't like such kind fo cookies.

Hope this helps

[Lutz Bliska]

Hi @James Hazelwood 

I'm back on this issue. I realised that Addon Connect properties are not a good choice because as you and @Eero Tapio Kaukonen said before ->  it's standalone.

In my case i only wan't to store username and password and did find a way for encryption using 'crypto' module. So for that case i don't want to setup a new database infrastructure on my host server... so is it possible to store the encrypted username and password somewhere at the Atlassian user profile ? so that these informations are user specific ? In case yes, how can do this ?

Thanks again

[James Hazelwood]

I'd suggest giving the user entity property a try - I believe access to those properties is limited to the logged-in user (but I'd test this out first). Is this what you mean by storing the credentials "at the Atlassian user profile"?

[Lutz Bliska]

Hi @James Hazelwood, that's exactly what i'm looking for. A way to store encrypted 3rd-party user-credentials in e.g. properties limited to the logged-in confluence user. So i 'm able to use the stored 3rd-party user-credentials in my Atlassian connect addon and i don't need to manage/setup a own user-database outside the Atlassian environment. 

[Lutz Bliska]

Hello Eero

Sorry for my late reply.

The 3rd party api supports no OAuth or OAuth2, so wie need to store username and password via the Confluence add-on using Atlassian connect.

How can i store username and password encrypt in the Confluence add-on properties ? Are there any atlassian libraries available for encryption ?

Thank you for your support.

Regards

[James Hazelwood]

Hi @Lutz Bliska,

If you do need to store the username and password rather than asking the user for them each time, how you store those credentials is up to you. You don't need to use add-on properties on the host, you can store whatever you like in your own service's database. Your add-on is a standalone application, as @Eero Tapio Kaukonen said.

Atlassian offers a couple of frameworks for handling Connect-related concerns, but not general-purpose libraries for things like encryption. That will depend on the language you are using, and how you want to do the encryption. Note that if you are storing and retrieving the credentials without user involvement, no encryption solution is going to be bulletproof, because you'll need to store the key somewhere as well.

I hope that helps.