unity-idm-discuss

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

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

Dear Krzysztof,

We encountered a problem with the names of groups, which was created by
groupadministrators in upman endpoint. The name of the group which is
released in groups attribute differs from the name which entered the
user. It seems that unity creates a name randomly and the entered name
is only used as display name.

I agree that the group administrators should only enter one name and
not two like the unity administrators can do. But the information is
used for group based access management on service provider level. If
the groupname differs from the name which was entered by the group
administrators, this is not possible.

What is the reason for the randomly generated grounames? Can this
behaviour changed?

Cheers,
Sander
-- 
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
-----------------------------------------------------------------------
-----------------------------------------------------------------------

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

[Krzysztof B. <kb...@un...>]

Dear Sander,

W dniu 31.07.2020 o 07:49, Sander Apweiler pisze:
> Dear Krzysztof,
>
> We encountered a problem with the names of groups, which was created by
> groupadministrators in upman endpoint. The name of the group which is
> released in groups attribute differs from the name which entered the
> user. It seems that unity creates a name randomly and the entered name
> is only used as display name.
>
> I agree that the group administrators should only enter one name and
> not two like the unity administrators can do. But the information is
> used for group based access management on service provider level. If
> the groupname differs from the name which was entered by the group
> administrators, this is not possible.
>
> What is the reason for the randomly generated grounames? Can this
> behaviour changed?

The group "internal" name, or its identifier, is set in stone. On the 
other hand the displayed name can be changed at will.

If admin can define the internal name, then it will have a semantic name 
typically. And this leads to troubles ("err I named it /cookies, but 
should be /chockolate-bars really"). Also group names when used 
externally should not relay on displayed name but on some stable id - 
what is the internal name.

BTW in the full unity this should be the same, and is not only because 
of the legacy of in-file configurations, where software can not assign 
ids on its own.

All in all I would advise to simply use the identifiers externally, 
especially in policies. If this is hard let me know why precisely; 
chances are I'll be able to help as we use this approach in many 
non-upman scenarios too. Or if not, we can think about an improvement then.

Best
Krzysztof

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

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

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.

Cheers,
Sander

On Sun, 2020-08-02 at 00:05 +0200, Krzysztof Benedyczak wrote:
> Dear Sander,
> 
> W dniu 31.07.2020 o 07:49, Sander Apweiler pisze:
> > Dear Krzysztof,
> > 
> > We encountered a problem with the names of groups, which was
> > created by
> > groupadministrators in upman endpoint. The name of the group which
> > is
> > released in groups attribute differs from the name which entered
> > the
> > user. It seems that unity creates a name randomly and the entered
> > name
> > is only used as display name.
> > 
> > I agree that the group administrators should only enter one name
> > and
> > not two like the unity administrators can do. But the information
> > is
> > used for group based access management on service provider level.
> > If
> > the groupname differs from the name which was entered by the group
> > administrators, this is not possible.
> > 
> > What is the reason for the randomly generated grounames? Can this
> > behaviour changed?
> 
> The group "internal" name, or its identifier, is set in stone. On
> the 
> other hand the displayed name can be changed at will.
> 
> If admin can define the internal name, then it will have a semantic
> name 
> typically. And this leads to troubles ("err I named it /cookies, but 
> should be /chockolate-bars really"). Also group names when used 
> externally should not relay on displayed name but on some stable id
> - 
> what is the internal name.
> 
> BTW in the full unity this should be the same, and is not only
> because 
> of the legacy of in-file configurations, where software can not
> assign 
> ids on its own.
> 
> All in all I would advise to simply use the identifiers externally, 
> especially in policies. If this is hard let me know why precisely; 
> chances are I'll be able to help as we use this approach in many 
> non-upman scenarios too. Or if not, we can think about an improvement
> then.
> 
> Best
> Krzysztof
> 
> 
-- 
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
-----------------------------------------------------------------------
-----------------------------------------------------------------------

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

[Krzysztof B. <kb...@un...>]

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.e. on output profile/protocol etc I would rather send 'NNE09' as the 
identifier and configure all policies around this - this is stable 
identifier. If you program around displayed name then... who knows what 
needs to be updated after some upman admin "improves" the displayed name?

I agree that giving access to displayed name (also in output profile) 
makes sense in general, to add some human readable context (useful e.g. 
for debuggin, initial config) but the base thing for me is the stable 
identifier.

What do you think?

KB

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

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

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.

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.

The next scenario is that a research community might have their groups
on several environments and want to have the same name on every
services. Here does the identifier also not work. Sadly such small
things might make the decision if the service is used or not.

To make it short there are scenarios where the opposite flow does not
work.
> I.e. on output profile/protocol etc I would rather send 'NNE09' as
> the 
> identifier and configure all policies around this - this is stable 
> identifier. If you program around displayed name then... who knows
> what 
> needs to be updated after some upman admin "improves" the displayed
> name?
Changing the display name would be the the short was for creating a new
group with the same members and removing the old group. Which would
lead of course to changed access permissions on the SP, which use the
group based access. Having no access to the resources are also possible
in this case.
> 
> I agree that giving access to displayed name (also in output
> profile) 
> makes sense in general, to add some human readable context (useful
> e.g. 
> for debuggin, initial config) but the base thing for me is the
> stable 
> identifier.
> 
> What do you think?
I agree that having a unique identifier is necessary for unity. But
there are different scenarios where the displayname need to be released
to the service providers instead of the identifier.

Cheers,
Sander
> 
> KB
> 
> 
-- 
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
-----------------------------------------------------------------------
-----------------------------------------------------------------------

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

[Krzysztof B. <kb...@un...>]

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?

> 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.

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

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

[Marcus H. <ha...@ki...>]

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

-- 
Marcus.

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
-----------------------------------------------------------------------
-----------------------------------------------------------------------

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

[Krzysztof B. <kb...@un...>]

Hi Sander,

W dniu 11.08.2020 o 09:26, Sander Apweiler pisze:
> 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.

OK, so that's the only request? I.e. to be able to access in output 
profile the displayed name of a group, giving its internal name as an 
argument, as follows:

grpDisplayedName['/ABC']

returning:

MyTestGroup

Can you confirm please? Or there is more that needs to be changed?

Thanks
Krzysztof

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

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

Good morning Krzysztof,
yes this would the only request. I think we can do the transformation
by ourself having this option. It does not make the group creation more
complex for users more complex.

Cheers,
Sander

On Tue, 2020-08-11 at 20:30 +0200, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> W dniu 11.08.2020 o 09:26, Sander Apweiler pisze:
> > 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.
> 
> OK, so that's the only request? I.e. to be able to access in output 
> profile the displayed name of a group, giving its internal name as
> an 
> argument, as follows:
> 
> grpDisplayedName['/ABC']
> 
> returning:
> 
> MyTestGroup
> 
> Can you confirm please? Or there is more that needs to be changed?
> 
> Thanks
> Krzysztof
> 
> 
-- 
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
-----------------------------------------------------------------------
-----------------------------------------------------------------------

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

[Krzysztof B. <kb...@un...>]

W dniu 12.08.2020 o 07:03, Sander Apweiler pisze:
> Good morning Krzysztof,
> yes this would the only request. I think we can do the transformation
> by ourself having this option. It does not make the group creation more
> complex for users more complex.

OK - ticketized.

Thanks,
Krzysztof