Re: [Unity-idm-discuss] Additional attribute source

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

Hi Krzysztof,

sorry for the late reply. I'll try to explain it with an bigger
example.

We have the following services:
- A: external IdP
- B: unity as proxy IdP
- C: additional attribute service
- D: some other service

We have the following user:
- 1: admin of C
- 2: normal user, wants to use D

Workflow:
- Any user logged in into C or D is authenticated by B
- C uses only attributes provided from B or A (through B)
- 1 can create additional attributes or role for 2 in C,
- B consumes and stores the additional attributes about 2 from C
- if 2 uses D uses attributes provided by B and C (through B)

Or with an more concrete example.
Within C user 1 creates a quota for user 2. This quota is a storage
limitation for Nextcloud (D). Unity get this additional attribute from
C. If 2 sing in into Nextcloud unity provides the following attributes:
- unity persisten identifier
- email (provided from home IdP to unity)
- CN (provided from home IdP to unity or entered during the
registration)
- quota (provided from additional attribute source to unity)

Hopefully it is more understandable. If not let me know and I try to
find another explanation after my holidays.

Best regards,
Sander

Am Donnerstag, den 24.08.2017, 23:48 +0200 schrieb Krzysztof
Benedyczak:
> Sander,
> 
> W dniu 23.08.2017 o 09:59, Sander Apweiler pisze:
> > Hi,
> > 
> > In our project is planed to use an additional attribute source for
> > registered users. We want to extend authorization possibilities
> > with
> > this attribute source.
> > 
> > Unity (A) is a proxy IdP and all services within the project use A
> > for
> > the authentication. The integration with other IdPs and SPs is
> > already
> > done. The attribute service (B) uses unity for authentication too.
> > B is
> > not an IdP, it is a SP of A. The situation would look like this:
> > 
> > - The user authenticates at A (done)
> > - The login into B is done with A (done; mapping by persistent
> > identifier from A)
> > - A get some additional information (e.g. group membership) about
> > the
> > user from B
> > 
> > I know the possibility about adding attributes by the
> > administration
> > API. Is there another possibility to use additional attribute
> > sources
> > for registered users like described above?
> 
> I don't think I can follow your scenario. Can you provide more
> details? 
> What are those services (what protocols)? What is the sequence of 
> operations: when Unity should request those attributes? Reading your 
> example literally user logins to B via Unity, which asks B about 
> attributes of user - ? to provide them back to B?
> 
> 
> 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 Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
-----------------------------------------------------------------------