Re: [Unity-idm-discuss] Naming of groups created via upman

[Sander A. <sa....@fz...>]

Hi Krzysztof,
I think, having access to the group-displaynames in the
translationprofile would be very helpful. In this case we could
transform them with mvel statments to our needs. E.g. We could
transform /ABC/DEF into urn:geant_h-
df.de:group:MyTestGroup:subgroup1#...

where /ABC is MyTestGroup and .../DEF subgroup1 within MyTestGroup.

In this case you do not need to carry about the released information or
change the unity behaviour. Maybe other users want/need the current
behaviour.

Having this possibility would allow to create the entitlement according
to AARC G002 automatically for all groups, instead using attribute
statements.

Best regards,
Sander

On Tue, 2020-08-11 at 09:12 +0200, Marcus Hardt wrote:
> On 08/10/20 19:26, Krzysztof Benedyczak wrote:
> > Hi Sander,
> > 
> > W dniu 04.08.2020 o 15:01, Sander Apweiler pisze:
> > > Hi Krzysztof,
> > > 
> > > On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote:
> > > > Morning Sander,
> > > > 
> > > > W dniu 03.08.2020 o 08:39, Sander Apweiler pisze:
> > > > > Good morning Krzysztof,
> > > > > I agree that identifiers are needed. But is there a
> > > > > possibility to
> > > > > grab
> > > > > the displayname of a group, e.g. in output translation
> > > > > profile? In
> > > > > this
> > > > > case we could release the group membership information like
> > > > > the
> > > > > group
> > > > > administrators and service providers would expect them.
> > > > > 
> > > > > I'll give you an example. We have a group m-team which is
> > > > > managed
> > > > > by a
> > > > > group administrator. He created a subgroup feudal-developers
> > > > > and
> > > > > asked
> > > > > specific service providers to support his group /m-
> > > > > team/feudal-
> > > > > developers but the service provider only see /m-team/NNE09.
> > > > > 
> > > > > Having the possibility to access the displayname, we could
> > > > > create a
> > > > > new
> > > > > attribute containing the expected information.
> > > > Hmm I wonder whether this is the right path. Shouldn't this be
> > > > opposite?
> > > I would agree in a very closed SP audience, only. If you have a
> > > broader
> > > audience which are part of multiple federations, this may become
> > > problematically. You would need to have a unique identifier
> > > across
> > > several IdPs, which can not be guaranteed. And in this case you
> > > do not
> > > need to carry about the uniqueness of the information anymore.
> > 
> > I don't udnerstand. You have many clients (SPs), OK. There is Upman
> > instance
> > with some groups. SPs get attribute with group id (say /zxc). Where
> > is the
> > problem that instead you need "/my-important-group"?
> > 
> > I don't understand the passage about unique identifier across
> > several IdPs?
> 
> There are multiple points.
> 
> Firstly, if SPs only obtain an identifier (rather than a name) it
> will be very difficult to make sure that name is the same everywhere.
> 
> That is why everybody simply sent a list of groups.
> 
> Then people realized that different IdPs might issue the same group
> name
> in different contexts. That is why we wrote AARC-G002, that defines
> globally unique group names (using the eduperson_entitlement)
> 
> Then came reality, that struck us the fact that some SPs (the stupid
> SPs
> from below) simply display "the entry" (i.e. either group or
> eduperson_entitlement) to the user. For that GUIDs suck, for those
> group
> lists are acceptable, but those services can only bind to one proxy.
> 
> It be useful (I guess) for Sander, if the groups in unity correspond
> uniquely to their G002 representation.
> 
> Unity internal identifiers should not be exposed outside of unity.
> 
>  
> > > Another problem are stupid SPs which consume the information
> > > directly
> > > and displays it to the users. One example is Nextcloud which is
> > > able to
> > > consume the groups from IdP (unity in this case). But Nextcloud
> > > will
> > > create the groups with the names released by the IdP and if the
> > > user
> > > want to share information with the group, they need to know the
> > > identifier.
> > 
> > Properly this should be realized as follows: IdP (upman) releases
> > group id
> > (hidden to the user) and displayed name (presented). Internally
> > group id is
> > used.
> > 
> > If this is not doable (i.e. the software can not distinguish
> > identifier from
> > its displaied form) the only thing we can do is to have same
> > displayed name
> > and group id.
> 
> I'm not sure why the identifier needs to be exposed at all, but there
> may
> be use cases that I don't know.
> 
> M.
> 
>  
> > This would be extra feature in upman, an extra mode: group creation
> > would
> > use displayed name as group id. We can do it, but note that as soon
> > as
> > somebody changes group displayed name in upman (or unity console)
> > you will
> > have semantic mess in the infrastructure.
> > 
> > Does the above address your problem?
> > 
> > Cheers,
> > Krzysztof
> > 
> > 
> > 
> > _______________________________________________
> > Unity-idm-discuss mailing list
> > Uni...@li...
> > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------