atom feed9 messages in org.codehaus.sonar.devRe: [sonar-dev] Management of Sonar g...
FromSent OnAttachments
Evgeny MandrikovDec 29, 2011 3:09 am 
Julien HENRYDec 29, 2011 7:38 am 
Freddy MalletDec 29, 2011 1:01 pm 
Fabrice BellingardJan 3, 2012 2:32 am 
ALIX LOURMEJan 3, 2012 4:51 am 
Evgeny MandrikovJan 4, 2012 1:49 am 
Bertrand FRANCHETJan 4, 2012 2:32 am 
Evgeny MandrikovJan 4, 2012 2:38 am 
Freddy MalletJan 4, 2012 1:01 pm 
Subject:Re: [sonar-dev] Management of Sonar groups by external systems
From:Julien HENRY (henr@yahoo.fr)
Date:Dec 29, 2011 7:38:08 am
List:org.codehaus.sonar.dev

Hi Evgeny,

Could you also consider SONARPLUGINS-1311 in this discussion (mapping name/email
from LDAP)?

I really like the user/group/role management of Nexus (except that in Nexus this
is called user/role/privilege) :

role is a internal object (OK, this is what is done in Sonar) users can be internal and/or external (with Sonar, this is basically internal
only, with possibility to map password to an external LDAP, but for all users at
the same time) groups can be internal and/or external (with Sonar, you can have internal only) you can assign users or groups to roles (OK, this is what is done in Sonar)

From a functional point of view, I would like to be able to:   - manually create an internal user (set login/fullname/password/email...) =>
already implemented, except that I can't enable LDAP authentication if the user
doesn't exists in LDAP   - manually create an external user (select the provider, then only type login,
all others fields are provided)   - manually create an internal group (set the name of the group and add the
members) => already implemented   - manually create an external group (select the provider, then type group
name)   - manually assign role(s) to users and groups (can be internal or external) =>
already implemented

In case I really need to create a lot of users/groups (populate Sonar from a
LDAP for example), then I would develop a batch using WS API.

So in fact your 2 functionals approaches are not exclusive.

From API point of view, my first though is that option 1 seems better. But this
really only a feeling.

Login process:   - user enter login/password   - look for login in users table. If this is an internal user, check password
in DB, load email/fullname from DB. If this is an external user, ask the
provider to authenticate. Provider returns email/fullname.   - get all internal groups for the user   - get all external groups for the user (for each group provider, get groups
for username XX)   - get roles for the user/groups

As a result you would need 2 extension points:

public interface ExternalUsersProvider extends ServerExtension {   String getId(); //Return an unique identifier for the provider   boolean authenticate(String login, String password);

  UserDetails getUserDetails(String login);   List<String> getUsers(); //May return null if listing groups is not supported,
or too expensive }

public interface ExternalGroupsProvider extends ServerExtension {   String getId(); //Return an unique identifier for the provider   List<String> getUserGroups(String login);

  List<String> getGroups(); //May return null if listing groups is not
supported, or too expensive }

ExternalUsersProvider is basically an improvement over ExternalUsersProvider...

Listing users and groups may be expensive for a provider so this is an optional
feature that could be used to assist administrator when creating external
users/groups in Sonar UI.

The only point I have no good idea is about "self sign-in feature". Should we
create an internal user and ask user to provide details or check every provider
if there is a user with same login, and in this case don't let user provide
fullname/password/email but take the one from the provider?

++

Julien

________________________________ De : Evgeny Mandrikov <mand@gmail.com> À : Sonar Developers List <de@sonar.codehaus.org> Envoyé le : Jeudi 29 Décembre 2011 12h10 Objet : [sonar-dev] Management of Sonar groups by external systems

Hi all,

I'd like to start discussion about the ways to extend management of groups in
Sonar, related issues are :     * SONAR-2292     * LDAP Plugin : SONARPLUGINS-895     * Crowd Plugin : SONARPLUGINS-1046 For the moment Sonar allows to perform only password check using external
system and automatically create user in Sonar if this check was successful. The
missing piece is an ability to automatically associate user with some groups in
Sonar. And there is several ways to achieve this.

From a functional point of view there is several approaches :

    1. Groups are manually created through the Sonar web interface. When a user
logs in, we check authentication using external system. And also retrieve all
groups associated to this user, without taking into account groups not existing
in Sonar. Then we establish links between this Sonar user and Sonar groups, i.e.
removal of stale links and creation of new. This synchronization mechanism
between groups is replayed each time user logs in.     2. List of all groups automatically retrieved from external system and
replicated in Sonar, i.e. removal of stale and creation of new. Then
synchronization of groups for user as in approach 1. Also should be noted that groups in Sonar are completely useless, if they not
associated with roles in projects and this association in both cases will be
done through the Sonar web interface.

From an API point of view there is also several approaches :

    1. Sonar can query plugins to provide required information - e.g. list of
all groups, list of groups for user.     2. Sonar can provide API for plugins to create groups/users and links
between them. Would be nice to hear your thoughts / approaches / use-cases and so on about
this.

Best regards, Evgeny Mandrikov aka Godin <http://godin.net.ru> http://twitter.com/_godin_