Connecting Jira to Keycloak while getting informations about users and groups from LDAP

[František Špaček _MoroSystems_]

Hello,

I haven't been able to find any informations about this particular questions. I have done synchronizations itself with AD numerous of times, but now I am struggling a bit with this scenario:

Authentization in our network is done against IdP called Keycloak. We use Kerberos and we can force 2FA over Keycloak to certain users (as thats why we use it). Keycloak itself is federating users from LDAP and all things connected to users (groups, membership) is done directly in LDAP. Keycloak is also federating some other users from other systems, thats again why we use it.

Now I am struggling with Jira itself. When I autheticate against Keycloak, all I get is information about that given user (e.g. about his roles, his credentials etc.). But these roles must exists already in Jira as groups. Same applies to users themselves (as I don't want the users to be created automatically, if they don't exist, partially because user is authenticated everytime, even shouldn't have access to Jira). How can I get all the groups inside Jira, when Keycloak is unable to work as LDAP itself (or maybe I am missing something?)

What we want to achieve:

1. Federate all users from different systems (but most of them are in LDAP, like 99%) in one IdP system (which is currently Keycloak).
2. Create groups (or roles or whatever is best name for it) in one system and also manage membership for these groups.
3. Manage system access at one place (which should driven by some groups user belongs to - e.g. if user belongs to jira-core-users, he has access to Jira Core, if I add a new group "called" test, group should be created in Jira, and if I add user to this group, his membership should be synchronized to Jira too).

What we did now is that we added synchronization directly with LDAP (which help us achieve request number 2. and 3.) and authentication is done trough one of the SAML SSO plugins available on marketplace.

We struggle now, that user is able to login directly to Jira, because all his credentials are now in Jira. We are able to redirect automatically to Keycloak login, but then the are other places, where he can still login directly into Jira (e.g. app Mobile for Jira).

Rather that making a hack solution not to store passwords in Jira or not authenticating against LDAP, I want to achieve proper clean way to these three points. I am unsure that synchronizing LDAP to both Keycloak and Jira is needed, but I don't see any other solution how can I manage groups in LDAP.

Does anybody came across similiar problem, or maybe I am just misunderstanding the whole problem at all.

Actual status is drawn here:

 

[Christian Reichert (resolution)]

Hi @František Špaček _MoroSystems_,

I work for resolution - we have, similar to Jon, a SSO Plugin in the marketplace. Which you may have tested already as well. 

https://marketplace.atlassian.com/vendors/1210947/resolution-reichert-network-solutions-gmbh

And like Jon says, we can create groups during SAML Login, as well as create & update Users including their group membership. Happy to help you figure out how to map groups in Keycloak via a screenshare if that's what you like to do.

However.

Just in time provisioning with SAML is not perfect - it only happens during login of the User. That means User only exist once they have logged in once - updated group memberships only happen on the next login etc. You get the idea. 
Also since that only happens during a successful login - we cannot disable Users. You need to have another route to free up licenses for example.

So if you have a LDAP Server already, that stores all the User Information - in my book synchronising Jira against that LDAP & using one of the SAML Plugins to only do the authentication part, would be the superior solution.

Anyway if you like some screenshare help with you setup let us know.

Cheers,
   Christian

[František Špaček _MoroSystems_]

Hello @Christian Reichert (resolution),

thanks for the confirmation of what I have been thinking about when I created this question. So I will need to connect Jira to both Keycloak trough SAML plugin and directly to LDAP to get users, groups and group membership immediately without need to wait for succesful user log in.

The problem is that I need to somehow disable whole log in process which is presented in Jira and redirect to Keycloak, because if I connect Jira to LDAP, it allows users to authenticate against LDAP directly, which is what I don't want to.

Thanks again and have a nice day.

[Christian Reichert (resolution)]

Hi @František Špaček _MoroSystems_,

interested in your thinking here - why would you like to prohibit people from authenticating via LDAP.

Speaking for our Plugin for now - 

When you have turned on automatic redirection then people never really see the Username/Password Login Screen. To get to it, they need a specially crafted URL (the login url with ?nosso appended). But even that you can turn off.

So the only place left for example is like you say some 3rd Party Apps. 

There is some positives about this as well, as you have a fallback method should you encounter Issues with SAML/your Keycloak IdP then you just turn off the redirection and 99% of your Users can still login.

This is probably more a matter of taste rather than one the right solution, the other isn't. I generally find with LDAP & coupled with SSO you get the best of both worlds.

But going back to your original setup:

The advice I would give you ...

- For the 99% of Users that are in LDAP, use the direct LDAP to keep those users synchronized & updated. Do the SSO via Plugin/Keycloak.

- For the 1% that are federated and not in Keycloak, let the SSO Plugin create and updated these Users. Make sure you have a process to clean-up the dsiabled one's, once in a while.

- If you really want people not to login via Username/Password, then open a support request with us: https://resolution.de/go/support - we've just implemented that for a few of our larger customers & we can give you access to the solution when you use our plugin. We'll integrate it at some point down the roadmap, but currently it still requires some manual steps, which is why we didn't publish it.

Cheers,
   Christian

[František Špaček _MoroSystems_]

Hello @Christian Reichert (resolution),

we want to prohibit users for using directly LDAP, because the whole company uses Keycloak as main place to log in (it is already combined with Kerberos, 2FA etc.) and we wanted to maintain same route for all apps we have in our network (not all of them Atlassian, most of them are not). Now we are in state where we are managing users and groups in LDAP along with the membership. Users are then federated in Keycloak along with some few other users from different systems (lets say some external workers dont need LDAP account, because its sometimes easir to handle it different way). Now we want to connect to Keycloak and make every user authentificate trough Keycloak, which is already in use and people are used to it.

Now we need to "add" Jira to this whole process. Requirements are that managing groups, people and membership stays in LDAP and login stays trough Keycloak because of the Kerberos, 2FA etc.

I am rather talking about whether our thinking is right or wrong with connecting Jira to LDAP to get users/groups/memberships and connecting it to Keycloak for authenticating users. :-)

Have a nice day!

[s.v.shuvaev]

My company in the same way as author of this thread. We using keycloak as SSO and many applications (120 approximately) work fine. When it was time to add jira in our common auth flow, it was a big surprise for me, that jira does not have native saml or oauth provider and there only way to pay for that.

Atlassian marketplace provides it's own "sso for atlassian server and data center", which does not work with server, and work only with data center like someone wrote in reviews.

Very disappointed

[Christian Reichert (resolution)]

Hi @František Špaček _MoroSystems_

thanks for your answer. I see the advantage of everyone just using Keycloak as the central place. 

Out of the Box is what you are trying to do not possible with the Atlassian Applications, as you concluded.

If 3rd Party Apps is an Option then you could look at our SAML Single Sign On Apps - they can authenticate against Keycloak (or any other SAML 2.0 IdP) - but they can also *synchronize* Users via the Keycloak API into the Atlassian Application. So you would no longer need LDAP.

@s.v.shuvaev - I also understand your frustration and view that this should be standard functionality for Atlassian to provide. However I am not from Atlassian, so I can't discuss or argue their rational for not doing this. However what I can do, I point out that there is a Solution available from us in the markteplace.

Cheers,
Chris

P.S. Full disclosure, I work for resolution, a marketplace vendor.

[František Špaček _MoroSystems_]

Hey @cr ,

thanks for pointing that out. I am happy there finally is a solution to get federated users and groups from Keycloack a sync them into Atlassian applications. I will have it in my mind for all new implementations we are doing for our customers, sadly this one already went different way without your awesome plugin (topic is already over 1 year old).

Could you please copy/paste your post as a new one to this thread so I can accept it?

Thanks!

[Christian Reichert (resolution)]

Hi @František Špaček _MoroSystems_ ,

thanks for the Feedback - I thought that might be the case and at that time we dind't have the User Synchronisation Features that we have today. But with @s.v.shuvaev update to the Question I though it might be worth to provide an update view on what's possible.

Cheers,
Chris

[Jon Espen Ingvaldsen Kantega SSO]

Hi František.

I work at Kantega SSO, the vendor of https://marketplace.atlassian.com/apps/1211923/jira-single-sign-on-sso-saml-kerberos?hosting=server&tab=overview.

This add-on supports SSO with Keycloak over SAML (setup guide), and is also able to handle your group management requirements. With our add-on, you can assign group memberships at SSO login. You can assign both custom groups to specific users (based on group membership information in the SAML responses) and default group memberships (in the case that the necessary groups memberships are not present in the user directory or provided in the SAML response from the IdP).

We are happy to help you set the configurations right, and please reach out to our support team if you struggle.

Regards,
Jon Espen
Kantega SSO

[František Špaček _MoroSystems_]

Hello Jon,

 thanks for your reply. I am rather looking for something a bit different - and thats managing all groups outside Jira and synchronizing them so I can work with them inside Jira.

I have already tried connecting Jira over different SSO solutions, your included, but my problem consits of something maybe a bit deeper, or something a bit different. The requirement is create the groups and manage memberships outside Jira (so nobody want to create groups directly in Jira), but after creating them outside the Jira (in some kind of IdM or IAM system), the want these groups to get synchronized in Jira so we can use them as roles in projects etc.

I am unsure whether I can get groups, which exists somewhere in IdM or IAM system, over SAML, but I don't think so, as SAML response return informations about users, who is trying to log in.

Maybe I am just missing something.

Thank again and have a nice day!

[Jon Espen Ingvaldsen Kantega SSO]

Hi again František.

It might be that you have to create and manage the groups inside of Jira manually. Note, however, that you can send group membership claims from many of the most common Idps, Keycloak included.

We have set up SAML authentication through Keycloak in our lab, and this setup sends group memberships as a part of the SAML responses (see the five role attributes in the Keycloak SAML response below):

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://issues.example.com/plugins/servlet/no.kantega.saml/sp/9p5o4zx2jqqq/login" ID="ID_05543ee9-44b3-465b-a838-1819bc84d3f2" InResponseTo="_ac82cab3738cceb8d337cb119b3a001d" IssueInstant="2018-09-27T14:52:51.669Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
   <saml:Issuer>https://keycloak.example.com/auth/realms/example.com</saml:Issuer>
   <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      <dsig:SignedInfo>
         <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
         <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
         <dsig:Reference URI="#ID_05543ee9-44b3-465b-a838-1819bc84d3f2">
            <dsig:Transforms>
               <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
               <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </dsig:Transforms>
            <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
            <dsig:DigestValue>upULU9z8SapAOPFer4WGZpV18NgyYQsh4LYU0IEBfYo=</dsig:DigestValue>
         </dsig:Reference>
      </dsig:SignedInfo>
      <dsig:SignatureValue>KjfRLBx2t4v179zDbCrqHTsoPZzZxw0R9Pqp6KXJds+ouyF2k2U7fEEqJ6UDgk4I2htUiGcnRqn3mE2ZMQ+WbIkJCgpHDLdL1oy7kBkoihUH5Su0SkPG7rjzX3Ib/qy31JU/G7HWSC0suqYXNta4+dmIpNtubNX3PSP/NK5E9MfgObW9Ibr0pANmiOzfiG7fGI2sA7WMZlab2ujzQPXZunJc0Yvf4eZt4MRrVMv7rcf97SiMc6Ox7qSSw88T/MTp/BA9DUfl42rv3R4eHf9M6yygQk/9/LGASK5lBAtJ887WjbnMDbCMIg+4a1aYUP7msFhUzvfKPt9ALMyio2FdAw==</dsig:SignatureValue>
      <dsig:KeyInfo>
         <dsig:KeyName>LnnRsTmmHEXqLLZyu6yfIK3tG0PkRdiEs6E6UUyVR_Q</dsig:KeyName>
         <dsig:X509Data>
            <dsig:X509Certificate>MIICpTCCAY0CBgFf5K7K/DANBgkqhkiG9w0BAQsFADAWMRQwEgYDVQQDDAtleGFtcGxlLmNvbTAeFw0xNzExMjIxNzAxMjFaFw0yNzExMjIxNzAzMDFaMBYxFDASBgNVBAMMC2V4YW1wbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl63Wasr6efQJjZZ2pjV5KGCtclA2caTus1zJBn871HsaWzwOcvfgheZhO0SKBhW4LTePZk62HyABftoG9qH/9Yh3ybDjzXCRRiZ7tIzvlrgnfQNJh2T/mo+kHEopNbuEUiTbCWPLY1Uv0DwU72l+SHqo9qgXwA0RYsJ1BD1RvQ0Vs9Op4VGgyawdyyT/ysF55ojcYnHnMfRnPHIA+UOZPqp0zwy1EbG709kf5FOMJPjjyuU6w7uB1IPMlODcJMH431JUWZiiKTgETgv9PqY8WoZ5goJ6Houe/dlYs7iyhKMvbgNC3riWUbrHDPGb4kIb3rciLB/+ZoODH0vP9HzwZwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBTpVhFTqCi8NUCEObbH73P+W4eJSU/QPEtg9KCRSH5ieqxpg+fnXE1TlbbEH/j57xxG4ltimJUf1W0Kvy/JaZvO4oZMqtHv1QfOdb358/0IPWPFLyOX22kMkwKSLcAR8w/2dpzeOsEBxK3nRLzKsBcpTERumbt5KG5Y5o+q+qllpBLEf4lBP+KyAD3IlZlJd5p+FEr4mG8zIRTM3L8F6vyM+X71s1uWkuc808YpLDA3gNKcgFBy2MtZFFARm1J2eodJVtF9i+mxUmC8DKpq/39sorAvV/nVMkIiDAA8tVsHLiPz4qWi4nPUhoMNpk+c7OD/cpYv2BANx/j0XjVHuLQ</dsig:X509Certificate>
         </dsig:X509Data>
         <dsig:KeyValue>
            <dsig:RSAKeyValue>
               <dsig:Modulus>l63Wasr6efQJjZZ2pjV5KGCtclA2caTus1zJBn871HsaWzwOcvfgheZhO0SKBhW4LTePZk62HyABftoG9qH/9Yh3ybDjzXCRRiZ7tIzvlrgnfQNJh2T/mo+kHEopNbuEUiTbCWPLY1Uv0DwU72l+SHqo9qgXwA0RYsJ1BD1RvQ0Vs9Op4VGgyawdyyT/ysF55ojcYnHnMfRnPHIA+UOZPqp0zwy1EbG709kf5FOMJPjjyuU6w7uB1IPMlODcJMH431JUWZiiKTgETgv9PqY8WoZ5goJ6Houe/dlYs7iyhKMvbgNC3riWUbrHDPGb4kIb3rciLB/+ZoODH0vP9HzwZw==</dsig:Modulus>
               <dsig:Exponent>AQAB</dsig:Exponent>
            </dsig:RSAKeyValue>
         </dsig:KeyValue>
      </dsig:KeyInfo>
   </dsig:Signature>
   <samlp:Status>
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
   </samlp:Status>
   <saml:Assertion ID="ID_5fc77263-f5ee-479f-8aed-3c675bc52bfc" IssueInstant="2018-09-27T14:52:51.665Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
      <saml:Issuer>https://keycloak.example.com/auth/realms/example.com</saml:Issuer>
      <saml:Subject>
         <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">steinar.line@example.com</saml:NameID>
         <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml:SubjectConfirmationData InResponseTo="_ac82cab3738cceb8d337cb119b3a001d" NotOnOrAfter="2018-09-27T14:57:49.665Z" Recipient="https://issues.example.com/plugins/servlet/no.kantega.saml/sp/9p5o4zx2jqqq/login"/>
         </saml:SubjectConfirmation>
      </saml:Subject>
      <saml:Conditions NotBefore="2018-09-27T14:52:49.665Z" NotOnOrAfter="2018-09-27T14:53:49.665Z">
         <saml:AudienceRestriction>
            <saml:Audience>https://issues.example.com/plugins/servlet/no.kantega.saml/sp/9p5o4zx2jqqq/login</saml:Audience>
         </saml:AudienceRestriction>
      </saml:Conditions>
      <saml:AuthnStatement AuthnInstant="2018-09-27T14:52:51.670Z" SessionIndex="aefde835-507d-4262-b936-ae6f7552b510::702594e2-38af-4cb4-ae47-0604978606de">
         <saml:AuthnContext>
            <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
         </saml:AuthnContext>
      </saml:AuthnStatement>
      <saml:AttributeStatement>
         <saml:Attribute Name="Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">view-profile</saml:AttributeValue>
         </saml:Attribute>
         <saml:Attribute Name="Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">read-token</saml:AttributeValue>
         </saml:Attribute>
         <saml:Attribute Name="Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">manage-account</saml:AttributeValue>
         </saml:Attribute>
         <saml:Attribute Name="Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">manage-account-links</saml:AttributeValue>
         </saml:Attribute>
         <saml:Attribute Name="Role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">uma_authorization</saml:AttributeValue>
         </saml:Attribute>
      </saml:AttributeStatement>
   </saml:Assertion>
</samlp:Response>

Our documentation at: https://docs.kantega.no/display/KA/Managed+Groups

has a section labeled "Configure AD FS to send group claims". This explains how to configure this in ADFS. Please tell me if you struggle to do similar configurations in Keycloak. I can ask one of our Keycloak experts about how the settings for achieving this was done in our lab.

This might not solve your whole scenario, but hopefully the membership synchronization part of it.

Have a nice day!
-Jon Espen
Kantega SSO

[František Špaček _MoroSystems_]

Hello Jon,

thanks for the reply. I have seen this kind of reply from server via SAML, but my problem lies a bit somewhere else. I understand I can get groups this way, but what I want is to be able to use groups in Permission schemas and Project Roles before user actually log in with them. My flow with groups should be something like this:

1. Create/manage/delete groups somewhere in different system (e.g. LDAP).
2. Add this group to permission scheme / project role in Jira, test it and prepare the changes.
3. Populate group with users in system outside Jira (e.g. LDAP).

I know I can update user's groups with this SAML response and I understand it can even create non existing groups in Jira, but then I will be waiting till somebody with such groups will log in and after that I can start finally adding them project roles etc. That does not seems to be user friendly for me, even not for administrators.

Thanks and have a nice day!