Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

We use it at penn.  However, Atlassian removed support for externalized users/groups a while back.  I think no one runs Atlassian products that old anymore, so I need to update the docs for the new setup.

 

I believe the recommended approach is to read groups from LDAP which are provisioned from Grouper.  You need isMemberOf and hasMember.  You might need to integrate through Atlassian Crowd, not sure.

 

At Penn we only have isMemberOf.   The connector currently syncs groups to the Atlassian tables, and relies on Atlassian reading from the tables every hour approximately.  So, at Penn when we change an Atlassian group in grouper it takes generally an hour to see it reflected in Jira/Confluence.   However, sometimes it doesn’t work (refreshing the cache from the DB) for whatever reason, so we nightly restart Atlassian.

 

Are you interested in the new approach?

 

Note, last summer (last time I checked), one of Jira|Confluence has a user/grouper WS API.  But the other didn’t so I didn’t pursue it.  When they both do we could use that to provision from grouper.

 

Thanks

Chris

 

 

 

From: [mailto:] On Behalf Of Neha Deshpande
Sent: Wednesday, July 13, 2016 3:27 PM
To:
Subject: [grouper-users] Re: Grouper Atlassian Connector

 

Are there any universities who use Atlassian connector who we can hopefully talk to?

 

Thanks,

 

On Tue, Jul 12, 2016 at 4:55 PM, Neha Deshpande <> wrote:

Hello,

 

I am trying to use grouper for group management for our Atlassian tools and have been unsuccessful so far. I was able to follow steps as listed in https://spaces.internet2.edu/display/Grouper/Grouper+Atlassian+connector .

 

I  copy jars to JIRA and make updates to the osuser.xml file and migrate the JIRA groups and users to grouper. (I skipped the step where it sets privileges because I was not sure what it did) 

 

The group and membership information was not stored in groupbase and membershipbase tables as mentioned in the documentation so I did not need to truncate them. We are using JIRA version 5.9.5 maybe they changed that?

Any changes I make to JIRA groups in grouper are not reflected in JIRA.

 

 

This is what my grouper.client.properties looks like:

 

################################

## Atlassian connector settings

################################

 

# put a folder name that is the root for atlassian groups

atlassian.root = Atlassian

 

# atlassian source to use (leave blank for all sources)

atlassian.subject.search.sourceId = 

 

# atlassian search by id, identifier, or idOrIdentifer (idOrIdentifier is Grouper 2.0+)

atlassian.subject.search.subjectId = identifier

 

# number of minutes to cache reads

# defaults to 10.  Note, crank this up  to 25 hours if you are doing XMPP notifications

atlassian.cache.minutes = 10

 

# number of minutes to cache profile reads

# defaults to 10

atlassian.cache.profile.minutes = 20

 

# each cache has a failsafe cache, so that if grouper is down, and the data has been loaded, 

# since atlassian has been started, the stale verison of the data can be retrieved

atlassian.cache.failsafe.hours = 48

 

# list all sources here, and how to get the atlassian id

atlassian.source.jdbc.sourceId = jdbc

# should be "id" or an attribute name to get the identifier for atlassian

atlassian.source.jdbc.idOrAttribute = ID

# email attribute for this source (needed if using the ProfileProvider)

atlassian.source.jdbc.emailAttribute = EMAIL

# should be "name" or "description" or an attribute name to get the name for atlassian (needed if using the ProfileProvider)

atlassian.source.jdbc.nameAttribute = name

 

#atlassian name of group which has all users in it, e.g. jira-users

atlassian.usersGroup = jira-users

 

# grouper group name of all users that have ever been in atlassian (profile service has access to these).  Leave blank to

# just use the users group

atlassian.grouperAllUsersGroup = 

 

# if you are doing XMPP for cache clearing, set to true, and set the XMPP sections of this config

atlassian.registerXmppListeners = false

 

# if incremental changes come through, then dont clear now, clear sometime in the future so that multiple changes

# cause fewer cache refreshes.  Note that changes come through the change log so that they are already buffered a little bit

# this should probably at least be 15 seconds...

atlassian.xmppIncrementalClearCacheSecondsInFuture = 75

 

# if all users must be in atlassian.grouperAllUsersGroup, 

# or if lookups of old users can be done without having to be in this group

atlassian.requireGrouperAllUsersGroupForLookups = false

 

# groups which should be assigned to various privileges for new groups created in confluence

atlassian.updaters = 

atlassian.admins = 

atlassian.readers = 

 

# pretend these memberships exist (e.g. to bootstrap or for users not in grouper)

atlassian.autoadd.administrators.groupname = jira-administrators

atlassian.autoadd.administrators.usernames = admin

 

atlassian.autoadd.users.groupname = jira-users

atlassian.autoadd.users.usernames = admin

 

# users not in idm, this is needed if using the profile provider

atlassian.autoadd.admin.user.id = admin

atlassian.autoadd.admin.user.name = Atlassian ADMIN

atlassian.autoadd.admin.user.email =

 

 

#ignore calls on this user to the web service

atlassian.ws.users.to.ignore = admin

 

#put a valid subject id or identifier here for testing, and that user's email and name

atlassian.test.subjectIdOrIdentifier = 

atlassian.test.email = 

atlassian.test.name = 

 

# if you are using the edu.internet2.middleware.grouperAtlassianConnector.GrouperLoggingAccessProviderWrapper

# to log an access provider, set the underlying class here

atlassian.logging.accessProvider.class = com.atlassian.jira.user.osuser.JiraOFBizAccessProvider

 

# if you are using the edu.internet2.middleware.grouperAtlassianConnector.GrouperLoggingAccessProviderWrapper

# to log an access provider, set the underlying class here

atlassian.logging.profileProvider.class = com.atlassian.jira.user.osuser.JiraOFBizProfileProvider

 

# if using the external authenticator, then this says if we should store the user token in session

# as opposed to getting it from the external authentication each time

atlassian.authentication.cacheUserToken = false

 

# if using the external authenticator, then this is the request attribute where the principal name is

# note, if it is REMOTE_USER, that will already be checked

atlassian.authentication.requestPrincipalAttributeName =

 

# if you are not in prod, and you want to backdoor as someone else, put a parameter name here (e.g. gibberish alphanumeric, or backdoorNetid)

# and if that param is in the URL or posted to the application, it will be used.  Note, if you use this then cacheUserToken will be true

# since this will not be in the URL for every request

atlassian.authentication.backdoorRequestParameterName = 

 

# if you are not in prod, and you want to backdoor as someone else, put comma separated usernames here who

# are allowed to backdoor as someone else

atlassian.authentication.backdoorAllowedUsers = 

 

Thanks,

--

Neha Deshpande
IT Engineer
DIT - Enterprise Engineering
University of Maryland

 

--

Neha Deshpande
IT Engineer
DIT - Enterprise Engineering
University of Maryland