In implementing these interfaces for Grouper, this is what is needed:

http://www.opensymphony.com/osuser/api/com/opensymphony/user/provider/AccessProvider.html

Which is a subinterface of this one:

http://www.opensymphony.com/osuser/api/com/opensymphony/user/provider/UserProvider.html

Basically if the fifer API can do all this, and I rewrite the Grouper-Atlassian connector to use the fifer client (if we have one), then that connector could be used against any fifer compliant group store.

Operations

Add member

• Input takes a netId and a group name, and adds the user to the group
• Returns if the user was added or if the user was already a member

Remove member

• Input takes a netId and a group name, and removes the user from the group
• Returns if the user was removed or if the user was already not a member

Has member

• Input takes a netId and a group name
• Returns if the user is a member (note, Grouper returns if a member, if it is immediate or effective, though Atlassian does not care)

Create group

• Input takes the folder (namespace), and group name, and description, and the edit type (INSERT / UPDATE / INSERT_OR_UPDATE)
• Return doesn't matter

Assign privileges to group

• Input takes the group name, privilege (e.g. READ, UPDATE, ADMIN) and an assignee (in this case specified by subject source id, and subject lookup (group name))
• Return doesn't matter in this case, but will tell if it was it was already assigned or is a new assignment
• Note: this isnt specifically in the open symphony API, but when the user in atlassian creates the group, it needs to allow all of the institutions admins to manage the group, so there is a config file in atlassian that specifies who gets those privileges, the institution can wire it all together.

Delete group

• Input takes the folder (namespace), and group name
• Return doesnt matter, but is if the group was deleted or didnt exist

Get groups

• Input takes the folder root to search in, and a netId for a user, and returns the groups that the user is an immediate or effective member of
• Return the group names fully qualified by folder

Get users

• Input takes the group name, and the sources of subjects to look for (i.e. don't return the System subjects, or groups, just people), and subject attributes needed (netId)
• Return the subjects from the requseted sources, with subjectId (opaque), and whatever subject attributes were requested (netId)

Find group by name

• Input takes a group name
• The interface just needs to know if the group exists, in Grouper's case, it returns the group details (name, description, etc)
• Note, this is the same web service operation as "Find groups in folder"

Find groups in folder

• This is used for atlassian to know the complete list of groups.  The implementation of the connector knows that something is an atlassian group since it is in the atlassian folder (configured somewhere in the folder structure).  This could also be implemented with group "types" or labels on the group...
• Input takes a folder, in grouper's case also pass in if you want groups immediately in the folder, or if it can also be in any subfolder, in this case we need folder or subfolder
• The interface needs the group name returned, though grouper returns the group details (name, description, etc)
• Note, this is the same web service operation as "Find group by name"

Update group

• There is a "store" method in the interface for groups, which I would assume would edit the attributes, though the only attribute Atlassian uses is group name, and there is no way to edit that, so in this case I think the operation is a no-op, and only in the UserProvider interface for other reasons than for groups...

Lookup subject

• Input takes a set of sources to look in, and a subject ID or identifier (depending on config)
• Return the subject
• This is for the "handles()" method which is supposed to return true if the adapter handles this subject, i.e. if the subject exists

Get members with attributes

• This is for the profile provider (to manage users/name/emails outside of Atlassian)
• Note, this could be implemented with a combination of other operations
• Input: group name from config file, subject sources to filter on, and attributes to return
• Return the members, with id, name, and email

Lookup subject with attributes

• This is for the profile provider (to manage users/name/emails outside of Atlassian)
• Input: username, optional group name from config file (if constraining Atlassian users to a certain group), subject sources to filter on, and attributes to return
• Return the subject, with id, name, and email

Notes

• It would be nice if the client could do some caching, since Atlassian does not do caching, and calls operations a LOT.  Right now the connector does the caching since the Grouper client does not yet cache...