4:47 p.m.
Hi everybody (and probably especially Stan and Stian),
In some of our projects we want to make heavy use of Keycloaks ability to obtain user
consent to third parties to access user data in our APIs.
In one project, the third parties provide modules that plug into our app and the user
should give his consent for this plugin at plugin installation time.
We plan to have one client for every plugin so the user can for every plugin decide which
scope of backend API access it wants to grant to the plugin.
I would be cool if asking for consent would be possible from the app in its UI at the
point when the user installs the plugin.
To do that, we would like to extend the account REST Api that’s currently in preview state
so it
a) covers the “applications” functionality (this is currently a TODO)
b) allows to create consents using the REST Api. I am well aware there might be
security implications here for clients that are essentially public, e.g. a rogue app could
manage consents of a user if he does not pay attention.
c) use a finer-grained role model for the accounts service, e.g. at least splitting up
view-account into view-profile+view-consents and manage-account into
manage-profile+manage-consents so we can control which clients may invoke the consents
functionality or we can prevent changing profile attributes
that come from an external IDP in our case.
What do you think about these changes/additions? Do they make sense? If yes, we would like
to contribute them.
Thanks and best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
9:56 a.m.
I assume it's not the third party application that is installing the
plugins, but rather some internal user management application? Having a
third-party app being able to manage consents would obviously defeat the
whole purpose of consent.
I don't have any issue with adding endpoints to be able to manage
applications and the introduction of fine-grained roles. Fine-grained roles
should be added for everything though, not just consents. Also, the
applications endpoint does more than just manage consents it also manages
offline access to applications, so that needs to be considered.
Would be good with a design proposal around this, to continue the
discussion there rather than fragmented on the ML.
On Wed, 22 May 2019 at 17:02, Schuster Sebastian (INST-CSS/BSV-OS2) <
Sebastian.Schuster(a)bosch-si.com> wrote:
Hi everybody (and probably especially Stan and Stian),
In some of our projects we want to make heavy use of Keycloaks ability to
obtain user consent to third parties to access user data in our APIs.
In one project, the third parties provide modules that plug into our app
and the user should give his consent for this plugin at plugin installation
time.
We plan to have one client for every plugin so the user can for every
plugin decide which scope of backend API access it wants to grant to the
plugin.
I would be cool if asking for consent would be possible from the app in
its UI at the point when the user installs the plugin.
To do that, we would like to extend the account REST Api that’s currently
in preview state so it
a) covers the “applications” functionality (this is currently a TODO)
b) allows to create consents using the REST Api. I am well aware there
might be security implications here for clients that are essentially
public, e.g. a rogue app could manage consents of a user if he does not pay
attention.
c) use a finer-grained role model for the accounts service, e.g. at
least splitting up view-account into view-profile+view-consents and
manage-account into manage-profile+manage-consents so we can control which
clients may invoke the consents functionality or we can prevent changing
profile attributes
that come from an external IDP in our case.
What do you think about these changes/additions? Do they make sense? If
yes, we would like to contribute them.
Thanks and best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr.
Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:39 p.m.
Will do!
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
Von: Stian Thorgersen <sthorger(a)redhat.com>
Gesendet: Donnerstag, 23. Mai 2019 09:57
An: Schuster Sebastian (INST-CSS/BSV-OS2) <Sebastian.Schuster(a)bosch-si.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>; Lanzendoerfer Jonas (AE-EB/ICO2)
<Jonas.Lanzendoerfer(a)de.bosch.com>
Betreff: Re: [keycloak-dev] User Consents via Account REST API
I assume it's not the third party application that is installing the plugins, but
rather some internal user management application? Having a third-party app being able to
manage consents would obviously defeat the whole purpose of consent.
I don't have any issue with adding endpoints to be able to manage applications and the
introduction of fine-grained roles. Fine-grained roles should be added for everything
though, not just consents. Also, the applications endpoint does more than just manage
consents it also manages offline access to applications, so that needs to be considered.
Would be good with a design proposal around this, to continue the discussion there rather
than fragmented on the ML.
On Wed, 22 May 2019 at 17:02, Schuster Sebastian (INST-CSS/BSV-OS2)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
wrote:
Hi everybody (and probably especially Stan and Stian),
In some of our projects we want to make heavy use of Keycloaks ability to obtain user
consent to third parties to access user data in our APIs.
In one project, the third parties provide modules that plug into our app and the user
should give his consent for this plugin at plugin installation time.
We plan to have one client for every plugin so the user can for every plugin decide which
scope of backend API access it wants to grant to the plugin.
I would be cool if asking for consent would be possible from the app in its UI at the
point when the user installs the plugin.
To do that, we would like to extend the account REST Api that’s currently in preview state
so it
a) covers the “applications” functionality (this is currently a TODO)
b) allows to create consents using the REST Api. I am well aware there might be
security implications here for clients that are essentially public, e.g. a rogue app could
manage consents of a user if he does not pay attention.
c) use a finer-grained role model for the accounts service, e.g. at least splitting up
view-account into view-profile+view-consents and manage-account into
manage-profile+manage-consents so we can control which clients may invoke the consents
functionality or we can prevent changing profile attributes
that come from an external IDP in our case.
What do you think about these changes/additions? Do they make sense? If yes, we would like
to contribute them.
Thanks and best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.co...
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:40 p.m.
Hi,
We created a ticket in the Keycloak Jira https://issues.jboss.org/browse/KEYCLOAK-10653
with some ideas on this issue. Feel free to comment on this.
Mit freundlichen Grüßen / Best regards
Leon Graser
INST-CSS/BSV-OS
Tel. +49 30 726112284 | Mobil +49 152 09198324
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> On
Behalf Of Schuster Sebastian (INST-CSS/BSV-OS2)
Sent: Freitag, 24. Mai 2019 15:39
To: stian(a)redhat.com
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Subject: Re: [keycloak-dev] User Consents via Account REST API
Will do!
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
Von: Stian Thorgersen <sthorger(a)redhat.com>
Gesendet: Donnerstag, 23. Mai 2019 09:57
An: Schuster Sebastian (INST-CSS/BSV-OS2) <Sebastian.Schuster(a)bosch-si.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>; Lanzendoerfer Jonas (AE-EB/ICO2)
<Jonas.Lanzendoerfer(a)de.bosch.com>
Betreff: Re: [keycloak-dev] User Consents via Account REST API
I assume it's not the third party application that is installing the plugins, but
rather some internal user management application? Having a third-party app being able to
manage consents would obviously defeat the whole purpose of consent.
I don't have any issue with adding endpoints to be able to manage applications and the
introduction of fine-grained roles. Fine-grained roles should be added for everything
though, not just consents. Also, the applications endpoint does more than just manage
consents it also manages offline access to applications, so that needs to be considered.
Would be good with a design proposal around this, to continue the discussion there rather
than fragmented on the ML.
On Wed, 22 May 2019 at 17:02, Schuster Sebastian (INST-CSS/BSV-OS2)
<Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
wrote:
Hi everybody (and probably especially Stan and Stian),
In some of our projects we want to make heavy use of Keycloaks ability to obtain user
consent to third parties to access user data in our APIs.
In one project, the third parties provide modules that plug into our app and the user
should give his consent for this plugin at plugin installation time.
We plan to have one client for every plugin so the user can for every plugin decide which
scope of backend API access it wants to grant to the plugin.
I would be cool if asking for consent would be possible from the app in its UI at the
point when the user installs the plugin.
To do that, we would like to extend the account REST Api that’s currently in preview state
so it
a) covers the “applications” functionality (this is currently a TODO)
b) allows to create consents using the REST Api. I am well aware there might be
security implications here for clients that are essentially public, e.g. a rogue app could
manage consents of a user if he does not pay attention.
c) use a finer-grained role model for the accounts service, e.g. at least splitting up
view-account into view-profile+view-consents and manage-account into
manage-profile+manage-consents so we can control which clients may invoke the consents
functionality or we can prevent changing profile attributes
that come from an external IDP in our case.
What do you think about these changes/additions? Do they make sense? If yes, we would like
to contribute them.
Thanks and best regards,
Sebastian
Mit freundlichen Grüßen / Best regards
Dr.-Ing. Sebastian Schuster
Open Source Services (INST-CSS/BSV-OS2)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY |
www.bosch-si.com<http://www.bosch-si.com><http://www.bosch-si.co...
Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 |
Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com><mailto:Sebastian.Schuster@bosch-si.com<mailto:Sebastian.Schuster@bosch-si.com>>
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber,
Michael Hahn, Dr. Aleksandar Mitrovic
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1779
days inactive
1801
days old
3 comments
3 participants
participants (3)
-
Graser Leon (INST-CSS/BSV-OS2) -
Schuster Sebastian (INST-CSS/BSV-OS2) -
Stian Thorgersen