From: Krzysztof B. <kb...@un...> - 2020-08-10 17:27:12
|
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 |