Issues with customer authenticator used for SSO with Siteminder

[Tim Theis]

I have extended the JiraSeraphAuthenticator to facilitate SSO to JIRA with our corporate Siteminder - this works successfully, but experiencing two issues:

1. Users are not automatically added to the jira-users group upon login and must be manually added.

I have attempted using the embedded crowd apis to addUserToGroup, but not clear on how to instantiate CrowdService. If this is the correct route to take, what needs to be configured (jira.xml?) to instantiate this class - below returns a null pointer exception?

protected static CrowdService getCrowdService()

{

return (CrowdService) ContainerManager.getComponent(crowdService);

}

2. Since implementing SSO, the login details (count, last login date) are no longer recorded for users. Please advise on what calls need to be made in the custom authenticator to continue recording the user login details.

Thanks.

[Vishnukumar Vasudevan]

Hi

Has anyone tried Crowd-SiteMinder integration ?

Regards, Vishnu.

[Manohar Venkataraman]

Regarding adding users to jira-user group, we have a kludge that we worked out using Jelly scripts that can extract all the users from a spreadsheet and directly import them into Jira including specifying which projects they need to be added to. I can post that to a separate Q/A if you think it would be useful.

I'm still trying to figure out how to fix the issue with spaces in the attachments so if you have any solutions out there that would be great. Not a showstopper, but annoying because it gets reported fairly frequently.

[J M]

So I have this all working now. My issue wasn't with JIRA itself, it was with how I was building the JAR. Now that I have wrestled the Atlassian SDK into shape, everything works fine. The code to add a user to jira-users that I have working is now this:

// What group should all users belong to
String DEFAULT_GROUP = new String("jira-users");

// getCrowdService() is another method in the SSO class
// that returns a com.atlassian.crowd.embedded.api.CrowdService 
CrowdService cs = getCrowdService();

// User here is a com.atlassian.crowd.embedded.api.User
// and username is String contaning the already-authenticated user
User user = cs.getUser(username);

// everyone has to be in a/the default group to login
if( ! cs.isUserMemberOfGroup(username,DEFAULT_GROUP) ){
  try{

    // Group here is a com.atlassian.crowd.embedded.api.Group
    Group defgroup = cs.getGroup(DEFAULT_GROUP);

    log.debug("user to add to " + DEFAULT_GROUP + " is " + user.getName());
    cs.addUserToGroup(user,defgroup);

    if( cs.isUserMemberOfGroup(username,DEFAULT_GROUP) ){
      log.info("user " + username + " added to group " + DEFAULT_GROUP);
    } else {
      log.info("user " + username + " could not be added to group " + DEFAULT_GROUP);
    }
  }
  catch(Exception e){
    log.info("critical failure adding use to " + DEFAULT_GROUP + ":" + e.getMessage());
  }
  log.debug("user " + username + "not in group " + DEFAULT_GROUP);
} else {
  log.debug("user " + username + "in group " + DEFAULT_GROUP);
}

[J M]

I have everything working to create sessions and making calls to Embedded Crowd except that I cannot get the method that actually add a user to a group to work - I get a NoSuchMethod error. So far:

CrowdService cs = getCrowdService();

// everyone has to be in a/the default group to login
if( ! cs.isUserMemberOfGroup(username,DEFAULT_GROUP) ){
  log.debug("user " + username + "not in group " + DEFAULT_GROUP);
  try{
    log.debug("trying to retrieve group " + DEFAULT_GROUP);
    Group defgroup = cs.getGroup(DEFAULT_GROUP);
    log.debug("group retrieved is named " + defgroup.getName());
    cs.addUserToGroup(user,defgroup);
    if( cs.isUserMemberOfGroup(username,DEFAULT_GROUP) ){
      log.info("user " + username + " added to group " + DEFAULT_GROUP);
    } else {
      log.info("user " + username + " could not be added to group " + DEFAULT_GROUP);
    }
  }
  catch(Exception e){
    log.info("critical failure adding use to " + DEFAULT_GROUP + ":" + e.getMessage());
  }
} else {
  log.debug("user " + username + "in group " + DEFAULT_GROUP);
}

In this code username and DEFAULT_GROUP are strings that are the username and "jira-users" respectively. This *should* all work and does except for the cs.addUserToGroup(user,defgroup); actually fails on execution with:

stacktrace = java.lang.NoSuchMethodError: com.atlassian.crowd.embedded.api.CrowdService.addUserToGroup(Lcom/atlassia
n/crowd/embedded/api/User;Lcom/atlassian/crowd/embedded/api/Group;)V

I'm calling it per the API documentation and other methods within the CrowdService class all work so I'm no sure at this point. Still poking at it when time permits...

[J M]

Also, you might want to add the jira and seraph tags to this Answer and perhaps an Atlassian person will see this.

[Tim Theis]

Hi JM,
Thanks for your comments... did you have any luck with your attempts with calls to the embedded Crowd?

Manohar-
We have not yet moved to 6.1, but will be at some point and I'll update with any insight.

[Manohar Venkataraman]

Sort of along these lines, I finally got Siteminder working with Jira 6.0.x by having someone here rebuild our Custom Jar. However when I tried to use the same Jar and server/web/seraph-config files with 6.1.x it no longer worked. So rather than perform our Production upgrade with 6.1 we have to go with 6.0.8. Not the worst thing in the world, but annoying since we're just postponing the pain. If anyone is able to successfully figure out how to integrate 6.1 with Siteminder please post the details. The actual Jira documentation for this integration out there is worthless. It has exactly the same information but with different dates, indicating its been updated when in reality it never has been: https://docs.atlassian.com/atlassian-seraph/latest/sso.html

[Tim Theis]

For 1&2, I don't have the details... they were addressed by the Siteminder admins. Yours should be familiar with any policy blocks.

For #2, this was directly related to its use of HEAD call that was also being blocked by the Siteminder policy.

3. I am utilizing the corporate LDAP for user account management, so do not need to do any maintanance of name/email... just need them to be added to the jira-users group (so for me this would be a great savings and convenience to the end users).

Thanks.

[J M]

Doing an SSO implementatino for JIRA is something I've been picking at for the last few weeks and I've run into the same issue. I think the issue is that there's some sort of missing information in the SSO documentation for JIRA. Even if you have the User Directory set to automatically add the user to 'jira-users' (and thus you're using the mode "Read Only with Local Groups"), this does not happen properly using any of the SSO example code that's out there for JIRA. At the same time I was debugging this, I also noticed that various ways of trying to determine if the user is already logged in get missed entirely and essentially every HTTP request to JIRA is starting a new session over again.

I believe there are some necessary calls to the embedded Crowd system to properly create the session and that would also do "first login" things properly. I'm experimenting with some code from Confluence to see if it's similar enough to hack through the issue.

FFR, this is the same issue I asked about at https://answers.atlassian.com/questions/222631/jira-ad-custom-sso.

[Manohar Venkataraman]

Ugh, I posted a long answer to this and somehow got logged out and had my answer wiped out.

1. Do you have any details regarding this? i.e. code like you posted above. I'm assuming without it I'll see problems when people try to post issue attachments containing spaces etc.

2. For some reason I'm unable to access Jira Marketplace, getting an error message 'The Jira server cannot be contacted'. Wondering if this is related to what you mentioned here.

3. Regarding your thread, for the first part I didn't realize there was a way that the user could automatically be created in the backend upon their first login via siteminder. However, given that as administrator I'd have to go in anyway and update their name/email in their profile, it doesn't seem like this would be much of a time savings.

For the metrics, I'm having the same issue and thought I'd posted a question although I can't find it. We have an agent that we're trying to set up that logs in every 5 minutes to check the status of Jira. Right now, we'd see a long string of logins for this agent. I only want to see the most recent login, which I assume is what you're trying to do. If I find a solution I'll let you know.

[Tim Theis]

Good to hear you're making progress... I ran into a few additional issues also that were tied back to the Siteminder configuration:

1. 5.2 introduced some additional special characters there were restricted by the policy and needed to be added (mostly affected filters involving date criteria and issue attachments containing spaces).

2. Marketplace: This uses a head call... and the policy for 4.x only allowed Get,Post,Put, Delete operations. JIRA uses just about everything.

Question on your custom authenticator - Do you have the issues that I have outlined in this thread originally? If not, would you share will me how you got around them? Thanks!

[Manohar Venkataraman]

Just had a breakthrough in that the Infrastructure team rebuilt the customauthenticator jar and we are now able to access Jira through Siteminder. There are a number of errors in the log and can't access the marketplace but I'm sure those will be easier issues to fix. I haven't used your change to seraph-config.xml yet, but may try it to see if it reduces the number of errors.

Right now we're only using Jira as an atlassian product, but over time the development groups might start looking at the other tools. Siteminder is mandated by the security team so we will definitely have to use it with those tools at that time.

[Tim Theis]

Hi Manohar-

I upgraded from 4.x to 5.2.5 a couple months ago, but still using a custom authenticator for SSO with Siteminder. The only thing that was required to change in order to get it to work was adding a new parameter into the seraph-config.xml (insert new login.forward.path) as indicated below:

<security-config>
    <parameters>
        ...
 
        <!--
          The path to *forward* to when the user tries to POST to a protected resource (rather than clicking on
          an explicit login link). Note that this is done using a servlet FORWARD, not a redirect. Information
          about the original request can be gotten from the javax.servlet.forward.* request attributes.
          At this point you will probably want to save the user's POST params so he can log in again and retry
          the POST.
          Defaults to undefined, in which case Seraph will just do a redirect instead of a FORWARD.
        -->
        <init-param>
            <param-name>login.forward.path</param-name>
            <param-value>/secure/XsrfErrorAction.jspa</param-value>
        </init-param>
 
        ...
    <parameters>
</security-config>

I never did resolve the original issues from this post, so if you have any insight there I would appreciate hearing from you!

Also, are you by change using Siteminder SSO with Stash, Bamboo or FishEye/Crucible?

Thanks and good luck with your upgrade,
Tim

[Manohar Venkataraman]

Tim, are you still using a custom authenticator for SSO with Jira 4.x and Siteminder? We're in the process of upgrading to Jira 6.0.1 but cannot get Siteminder to work. There seems to have been a change starting 5.0, but not sure what needs to be changed, server.xml/web.xml/seraph-config.xml/custom authenticator or all of the above.

If you have upgraded could really use your input: https://answers.atlassian.com/questions/178245/how-do-i-update-my-sso-siteminder-files-to-work-with-jira-6-0-1-from-4-4-3#

[PauloP]

Hi there

About auto-adding the users to the jira-users group, you have to enable this option in the external directory (Administration > USers Direcotry > Configuring the LDAP directory). Perhaps the following link could be useful:

https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP+Directory

Related to the user login details, this is related to the authentication method. So, I'd suggest to review this update procedure in your customer authentication. Also, the following link could be useful too:

https://confluence.atlassian.com/display/CROWD/Overview+of+SSO

Cheers,

Paulo Renato

[Tim Theis]

Thank you for your reply Paulo.

I should have provided more detail in my current setup that is not working:
- I am using ldap for user directory (Sun directory server) and it is setup as the 2nd directorory to the Internal directory.
- It is setup as Read Only, with Local Groups and the default group membership value is already set to "jira-users".
- The jira-users group is only an internal group and not an ldap group.
- jira-users is also specified in the global permissions for JIRA Users
- So all users in the company have a user entry, but only people that need to use JIRA are in the jira-users group... which still need to be manually setup since the default in not working.
- This is the reason I was looking into adding the group assignment into the custom authenticator code.

Your second link has me wondering if I'm approaching this wrong using the crowd apis... I'm not using "stand alone" crowd for user management (as described here: https://confluence.atlassian.com/display/JIRA044/Connecting+to+Crowd+or+Another+JIRA+Server+for+User+Management).

It is only the embedded crowd that is used, so I was attempting to use this class:
com.atlassian.crowd.embedded.api.CrowdService;

Should I be using the JIRA user/group apis?

Thanks again for you advise.

Tim

[Tim Theis]

I'm actually struggling with the difference between full Crowd integration and utilization of the embedded Crowd in OOTB JIRA.

What is the advantage to full integration with Crowd? We are currently not experiencing any deficiencies in the current setup except for the fact that users are not added to the jira-users group upon their initial login. I recognize that this is due to use of the custom authenticator to support Siteminder SSO, so want to explicitly include the group add in the authenticator code.

It doesn't seem that full integration will crowd would be necessary to implement this logic.