[keycloak-user] Inject (Keycloak)Principal
Juraci Paixão Kröhling
juraci at kroehling.de
Fri Mar 28 03:16:44 EDT 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Dirk,
It seems it's missing the @SecurityDomain("keycloak") in your service,
at the type level. If that's not the case, I can update the
"sample-ejb-roles" quickstart, adapted to use Keycloak, so you can
compare and check what's missing.
Just to confirm: have you also added the security-domain to the
standalone.xml? The instructions are at the end of section 6.2.1 from
the user guide:
http://docs.jboss.org/keycloak/docs/1.0-alpha-3/userguide/html_single/index.html#d4e485
Juca.
On 03/28/2014 01:31 AM, Dirk Franssen wrote:
> Hi,
>
> I was playing around with the examples, more specifically with the
> customer-portal-js which is accessing the database resource. In
> that CustomerService I was trying to get access to the Principal
> and trying to extend to return in addition the username of the
> logged-in user:
>
> @Path("customers") public class CustomerService {
>
> @Inject Principal principal;
>
> //@Context //SecurityContext sc; //Principal principal =
> sc.getUserPrincipal();
>
> //@Context //ContainerRequestContext request; //SecurityContext sc
> = request.getSecurityContext(); //Principal principal =
> sc.getUserPrincipal();
>
> @GET @Produces("application/json") @NoCache public List<String>
> getCustomers() { ArrayList<String> rtn = new ArrayList<String>();
> rtn.add("Bill Burke"); rtn.add("Stian Thorgersen"); rtn.add("Stan
> Silvert"); rtn.add("Gabriel Cardoso"); rtn.add("Viliam Rockai");
> rtn.add("Marek Posolda"); rtn.add("Boleslaw Dawidowicz");
> rtn.add(principal.getName()); //<--- add username to the list
> return rtn; } }
>
> But this throws a npe as the principal is always null. I noticed
> that the JaxrsBearerTokenFilter is adding to the
> ContainerRequestContext a new SecurityContex, of which the
> getUserPrincipal method returns the KeycloakPrincipal. But I can't
> figure out how to get access to this from the CustomerService.
>
> My intention is to verify if the logged-in user is accessing his
> own resources, and e.g. is not trying to update data of somebody
> else. E.g. the id should match principal.getName() in following:
>
> @POST @Path("/users/{id}/friends") public void
> addFriend(@PathParam("id") String userId, Friend friend) { ... }
>
> Any suggestions? It would be nice if, beside the KeycloakPrincipal
> is injectable, to be able to define something like @IsOwner:
>
> public void addFriend(@PathParam("id") @IsOwner String userId,
> Friend friend)
>
> or even more concise:
>
> public void addFriend(@IsOwner("id") String userId, Friend friend)
>
> Kind regards, Dirk Franssen
>
>
> On Thu, Mar 27, 2014 at 5:29 PM,
> <keycloak-user-request at lists.jboss.org
> <mailto:keycloak-user-request at lists.jboss.org>> wrote:
>
> Send keycloak-user mailing list submissions to
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/keycloak-user or, via
> email, send a message with subject or body 'help' to
> keycloak-user-request at lists.jboss.org
> <mailto:keycloak-user-request at lists.jboss.org>
>
> You can reach the person managing the list at
> keycloak-user-owner at lists.jboss.org
> <mailto:keycloak-user-owner at lists.jboss.org>
>
> When replying, please edit your Subject line so it is more
> specific than "Re: Contents of keycloak-user digest..."
>
>
> Today's Topics:
>
> 1. Re: Keycloak and AngularJS (Bill Burke) 2. Re: Keycloak and
> AngularJS (Stian Thorgersen) 3. Re: Keycloak and AngularJS (Nils
> Preusker) 4. Re: Keycloak and AngularJS (Bill Burke)
>
>
> ----------------------------------------------------------------------
>
> Message: 1 Date: Thu, 27 Mar 2014 11:39:07 -0400 From: Bill Burke
> <bburke at redhat.com <mailto:bburke at redhat.com>> Subject: Re:
> [keycloak-user] Keycloak and AngularJS To:
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org> Message-ID:
> <5334461B.8040202 at redhat.com <mailto:5334461B.8040202 at redhat.com>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> What I like about the current admin console approach is that there
> is no book keeping required by the browser. The Angular app has
> really no knowledge of how it is being secured as its all driven by
> the server. Also, you need to remember that the admin console was
> designed to be run in a non-Java EE, non-servlet environment.
> While this is a requirement for Keycloak, it may not be for your
> application. So, what I'm saying is that for your angular
> application, you could rely on the servlet container and keycloak
> adapter to maintain a session cookie and identity.
>
> What I like about the keycloak.js approach is that there is no
> server-side adapter required for the UI. The UI could be hosted
> off any number of static web sites and use CORS invocations to any
> number of Restful services.
>
> There's also the debate of public vs. confidential clients. The
> keycloak.js approach requires a public client. My understanding
> was that confidential clients exist so that only an authenticated
> client (client *NOT* user) is able to obtain an access token. I'm
> not exactly sure what additional security benefits are obtained
> here beyond this. I've been trying to ask this very question on
> OAuth mail lists but have been unable to get a response so far.
>
>
>
> On 3/27/2014 10:41 AM, Nils Preusker wrote:
>> Hi Stian and Bill,
>>
>> I've posted some questions regarding this topic before but I
> thought I'd
>> start a new thread to keep things focused:
>>
>> I'm writing an AngularJS application with Java EE 6/7 REST
>> (JAX-RS) backend modules. To add authentication and authorization
>> to this application, I'd like to use keycloak
>>
>> * as a user and role management front-end * to provide a
>> customizable login page (works very well by the way ;) * as an
>> OAuth 2.0 token provider * to add user and role information to
>> the HTTPRequests in my REST/ backend modules
>>
>> To do this, I'm currently looking at keycloak.js and the
> customer-app-js
>> example. However, I'm wondering whether this is really the best
>> way to go. In a reply to an earlier post of mine you mentioned
>> that the keycloak admin console is written in AngularJS and that
>> you are using HTTP-only cookies there.
>>
>> However, in keycloak.js and the customer-app-js example you are
>> retrieving the token in the JS app and adding an authorization
>> header with a bearer token to the HTTP requests.
>>
>> So here are my questions:
>>
>> * Is there a reason you are using two different approaches in
>> the
> admin
>> console and the official demo app? * which one of the two
>> approaches (bearer tokens vs. HTTP-only cookie) will you support/
>> will be the officially recommended one for HTML5/ client side
>> JavaScript applications in keycloak? * am I right in assuming
>> that you haven't quite decided yet which approach to use and that
>> you are still discussing this in the
> keycloak team?
>>
>> Looking forwards to your reply! Cheers, Nils
>>
>>
>> _______________________________________________ keycloak-user
>> mailing list keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
> -- Bill Burke JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> ------------------------------
>
> Message: 2 Date: Thu, 27 Mar 2014 12:18:01 -0400 (EDT) From: Stian
> Thorgersen <stian at redhat.com <mailto:stian at redhat.com>> Subject:
> Re: [keycloak-user] Keycloak and AngularJS To: Bill Burke
> <bburke at redhat.com <mailto:bburke at redhat.com>> Cc:
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org> Message-ID:
> <884719116.3009607.1395937081146.JavaMail.zimbra at redhat.com
> <mailto:884719116.3009607.1395937081146.JavaMail.zimbra at redhat.com>>
>
>
Content-Type: text/plain; charset=utf-8
>
> Personally, I think that in most cases for a client-side web app
> the best approach is to let the client-side do the oauth flow (the
> approach we're currently taking in keycloak.js). It does depend on
> your application though, and if you're application has a strict
> one html5 app calls one REST service then http-only cookies are an
> option. I don't see any real benefits of it though, and I believe
> it significantly complicates things.
>
> Have a look at
> http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/,
>
>
I think it provides a good summary of the pros of the token approach.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com
>> <mailto:bburke at redhat.com>> To: keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:
>> [keycloak-user] Keycloak and AngularJS
>>
>> What I like about the current admin console approach is that
>> there
> is no
>> book keeping required by the browser. The Angular app has really
>> no knowledge of how it is being secured as its all driven by the
>> server. Also, you need to remember that the admin console was
>> designed to
> be run
>> in a non-Java EE, non-servlet environment. While this is a
> requirement
>> for Keycloak, it may not be for your application. So, what I'm
>> saying is that for your angular application, you could rely on
>> the servlet container and keycloak adapter to maintain a session
>> cookie and
> identity.
>>
>> What I like about the keycloak.js approach is that there is no
>> server-side adapter required for the UI. The UI could be hosted
> off any
>> number of static web sites and use CORS invocations to any number
>> of Restful services.
>>
>> There's also the debate of public vs. confidential clients. The
>> keycloak.js approach requires a public client. My understanding
>> was that confidential clients exist so that only an authenticated
>> client (client *NOT* user) is able to obtain an access token.
>> I'm not
> exactly
>> sure what additional security benefits are obtained here beyond
>> this. I've been trying to ask this very question on OAuth mail
>> lists but
> have
>> been unable to get a response so far.
>>
>>
>>
>> On 3/27/2014 10:41 AM, Nils Preusker wrote:
>>> Hi Stian and Bill,
>>>
>>> I've posted some questions regarding this topic before but I
> thought I'd
>>> start a new thread to keep things focused:
>>>
>>> I'm writing an AngularJS application with Java EE 6/7 REST
>>> (JAX-RS) backend modules. To add authentication and
>>> authorization to this application, I'd like to use keycloak
>>>
>>> * as a user and role management front-end * to provide a
>>> customizable login page (works very well by the
> way ;)
>>> * as an OAuth 2.0 token provider * to add user and role
>>> information to the HTTPRequests in my REST/ backend modules
>>>
>>> To do this, I'm currently looking at keycloak.js and the
> customer-app-js
>>> example. However, I'm wondering whether this is really the
>>> best
> way to
>>> go. In a reply to an earlier post of mine you mentioned that
>>> the keycloak admin console is written in AngularJS and that you
>>> are
> using
>>> HTTP-only cookies there.
>>>
>>> However, in keycloak.js and the customer-app-js example you
>>> are retrieving the token in the JS app and adding an
>>> authorization
> header
>>> with a bearer token to the HTTP requests.
>>>
>>> So here are my questions:
>>>
>>> * Is there a reason you are using two different approaches in
> the admin
>>> console and the official demo app? * which one of the two
>>> approaches (bearer tokens vs. HTTP-only
> cookie)
>>> will you support/ will be the officially recommended one for
>>> HTML5/ client side JavaScript applications in keycloak? * am I
>>> right in assuming that you haven't quite decided yet which
>>> approach to use and that you are still discussing this in the
> keycloak
>>> team?
>>>
>>> Looking forwards to your reply! Cheers, Nils
>>>
>>>
>>> _______________________________________________ keycloak-user
>>> mailing list keycloak-user at lists.jboss.org
>>> <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>> -- Bill Burke JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________ keycloak-user
>> mailing list keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
> ------------------------------
>
> Message: 3 Date: Thu, 27 Mar 2014 17:24:06 +0100 From: Nils
> Preusker <n.preusker at gmail.com <mailto:n.preusker at gmail.com>>
> Subject: Re: [keycloak-user] Keycloak and AngularJS To:
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org> Message-ID:
>
> <CA+HCLu_XG0xu+KUALgxoDuAMftA=rBgV-eFhwbDvaxq48NiOwQ at mail.gmail.com
>
>
<mailto:rBgV-eFhwbDvaxq48NiOwQ at mail.gmail.com>>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Stian and Bill,
>
> thanks for your replies! I'll check out the blog post and try the
> approach with a web.xml and a keycloak.json in the backend for now.
> I'll keep you posted on what I end up with on the client side.
>
> Cheers, Nils
>
>
>
> On Thu, Mar 27, 2014 at 5:18 PM, Stian Thorgersen
> <stian at redhat.com <mailto:stian at redhat.com>> wrote:
>
>> Personally, I think that in most cases for a client-side web app
> the best
>> approach is to let the client-side do the oauth flow (the
>> approach
> we're
>> currently taking in keycloak.js). It does depend on your
>> application though, and if you're application has a strict one
>> html5 app calls
> one REST
>> service then http-only cookies are an option. I don't see any
>> real
> benefits
>> of it though, and I believe it significantly complicates things.
>>
>> Have a look at
>>
> http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/,
>
> I think it provides a good summary of the pros of the token
> approach.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com
>>> <mailto:bburke at redhat.com>> To: keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
>>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:
>>> [keycloak-user] Keycloak and AngularJS
>>>
>>> What I like about the current admin console approach is that
> there is no
>>> book keeping required by the browser. The Angular app has
>>> really no knowledge of how it is being secured as its all
>>> driven by the
> server.
>>> Also, you need to remember that the admin console was designed
> to be run
>>> in a non-Java EE, non-servlet environment. While this is a
> requirement
>>> for Keycloak, it may not be for your application. So, what
>>> I'm
> saying
>>> is that for your angular application, you could rely on the
>>> servlet container and keycloak adapter to maintain a session
>>> cookie and
> identity.
>>>
>>> What I like about the keycloak.js approach is that there is no
>>> server-side adapter required for the UI. The UI could be
>>> hosted
> off any
>>> number of static web sites and use CORS invocations to any
>>> number of Restful services.
>>>
>>> There's also the debate of public vs. confidential clients.
>>> The keycloak.js approach requires a public client. My
>>> understanding was that confidential clients exist so that only
>>> an authenticated client (client *NOT* user) is able to obtain
>>> an access token. I'm not
> exactly
>>> sure what additional security benefits are obtained here
>>> beyond
> this.
>>> I've been trying to ask this very question on OAuth mail lists
> but have
>>> been unable to get a response so far.
>>>
>>>
>>>
>>> On 3/27/2014 10:41 AM, Nils Preusker wrote:
>>>> Hi Stian and Bill,
>>>>
>>>> I've posted some questions regarding this topic before but I
> thought
>> I'd
>>>> start a new thread to keep things focused:
>>>>
>>>> I'm writing an AngularJS application with Java EE 6/7 REST
> (JAX-RS)
>>>> backend modules. To add authentication and authorization to
>>>> this application, I'd like to use keycloak
>>>>
>>>> * as a user and role management front-end * to provide a
>>>> customizable login page (works very well by the
> way ;)
>>>> * as an OAuth 2.0 token provider * to add user and role
>>>> information to the HTTPRequests in my REST/ backend modules
>>>>
>>>> To do this, I'm currently looking at keycloak.js and the
>> customer-app-js
>>>> example. However, I'm wondering whether this is really the
> best way to
>>>> go. In a reply to an earlier post of mine you mentioned that
>>>> the keycloak admin console is written in AngularJS and that
>>>> you
> are using
>>>> HTTP-only cookies there.
>>>>
>>>> However, in keycloak.js and the customer-app-js example you
>>>> are retrieving the token in the JS app and adding an
>>>> authorization
> header
>>>> with a bearer token to the HTTP requests.
>>>>
>>>> So here are my questions:
>>>>
>>>> * Is there a reason you are using two different approaches
>>>> in
> the admin
>>>> console and the official demo app? * which one of the two
>>>> approaches (bearer tokens vs. HTTP-only
> cookie)
>>>> will you support/ will be the officially recommended one for
> HTML5/
>>>> client side JavaScript applications in keycloak? * am I right
>>>> in assuming that you haven't quite decided yet which approach
>>>> to use and that you are still discussing this in the
> keycloak
>>>> team?
>>>>
>>>> Looking forwards to your reply! Cheers, Nils
>>>>
>>>>
>>>> _______________________________________________ keycloak-user
>>>> mailing list keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>> -- Bill Burke JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________ keycloak-user
>>> mailing list keycloak-user at lists.jboss.org
>>> <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>> _______________________________________________ keycloak-user
>> mailing list keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
> -------------- next part -------------- An HTML attachment was
> scrubbed... URL:
> http://lists.jboss.org/pipermail/keycloak-user/attachments/20140327/b8e5ee89/attachment-0001.html
>
> ------------------------------
>
> Message: 4 Date: Thu, 27 Mar 2014 12:29:54 -0400 From: Bill Burke
> <bburke at redhat.com <mailto:bburke at redhat.com>> Subject: Re:
> [keycloak-user] Keycloak and AngularJS To: Stian Thorgersen
> <stian at redhat.com <mailto:stian at redhat.com>> Cc:
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org> Message-ID:
> <53345202.4060105 at redhat.com <mailto:53345202.4060105 at redhat.com>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> One of the problems with the keycloak.js approach is that we have
> no way to perform a single log out or to force a logout of a
> specific user. I think the OpenID Connect spec may have a way with
> IFrames to do this sort of thing though. I didn't really get it at
> first glance though.
>
>
> On 3/27/2014 12:18 PM, Stian Thorgersen wrote:
>> Personally, I think that in most cases for a client-side web app
> the best approach is to let the client-side do the oauth flow (the
> approach we're currently taking in keycloak.js). It does depend on
> your application though, and if you're application has a strict
> one html5 app calls one REST service then http-only cookies are an
> option. I don't see any real benefits of it though, and I believe
> it significantly complicates things.
>>
>> Have a look at
> http://blog.auth0.com/2014/01/07/angularjs-authentication-with-cookies-vs-token/,
>
>
I think it provides a good summary of the pros of the token approach.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com
>>> <mailto:bburke at redhat.com>> To: keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
>>> Sent: Thursday, 27 March, 2014 3:39:07 PM Subject: Re:
>>> [keycloak-user] Keycloak and AngularJS
>>>
>>> What I like about the current admin console approach is that
> there is no
>>> book keeping required by the browser. The Angular app has
>>> really no knowledge of how it is being secured as its all
>>> driven by the server. Also, you need to remember that the admin
>>> console was designed to
> be run
>>> in a non-Java EE, non-servlet environment. While this is a
> requirement
>>> for Keycloak, it may not be for your application. So, what
>>> I'm
> saying
>>> is that for your angular application, you could rely on the
>>> servlet container and keycloak adapter to maintain a session
>>> cookie and
> identity.
>>>
>>> What I like about the keycloak.js approach is that there is no
>>> server-side adapter required for the UI. The UI could be
>>> hosted
> off any
>>> number of static web sites and use CORS invocations to any
>>> number of Restful services.
>>>
>>> There's also the debate of public vs. confidential clients.
>>> The keycloak.js approach requires a public client. My
>>> understanding was that confidential clients exist so that only
>>> an authenticated client (client *NOT* user) is able to obtain
>>> an access token. I'm not
> exactly
>>> sure what additional security benefits are obtained here beyond
>>> this. I've been trying to ask this very question on OAuth mail
>>> lists
> but have
>>> been unable to get a response so far.
>>>
>>>
>>>
>>> On 3/27/2014 10:41 AM, Nils Preusker wrote:
>>>> Hi Stian and Bill,
>>>>
>>>> I've posted some questions regarding this topic before but I
> thought I'd
>>>> start a new thread to keep things focused:
>>>>
>>>> I'm writing an AngularJS application with Java EE 6/7 REST
>>>> (JAX-RS) backend modules. To add authentication and
>>>> authorization to this application, I'd like to use keycloak
>>>>
>>>> * as a user and role management front-end * to provide a
>>>> customizable login page (works very well by the
> way ;)
>>>> * as an OAuth 2.0 token provider * to add user and role
>>>> information to the HTTPRequests in my REST/ backend modules
>>>>
>>>> To do this, I'm currently looking at keycloak.js and the
> customer-app-js
>>>> example. However, I'm wondering whether this is really the
>>>> best
> way to
>>>> go. In a reply to an earlier post of mine you mentioned that
>>>> the keycloak admin console is written in AngularJS and that
>>>> you are
> using
>>>> HTTP-only cookies there.
>>>>
>>>> However, in keycloak.js and the customer-app-js example you
>>>> are retrieving the token in the JS app and adding an
>>>> authorization
> header
>>>> with a bearer token to the HTTP requests.
>>>>
>>>> So here are my questions:
>>>>
>>>> * Is there a reason you are using two different approaches
>>>> in
> the admin
>>>> console and the official demo app? * which one of the two
>>>> approaches (bearer tokens vs. HTTP-only
> cookie)
>>>> will you support/ will be the officially recommended one for
>>>> HTML5/ client side JavaScript applications in keycloak? * am
>>>> I right in assuming that you haven't quite decided yet which
>>>> approach to use and that you are still discussing this in
>>>> the
> keycloak
>>>> team?
>>>>
>>>> Looking forwards to your reply! Cheers, Nils
>>>>
>>>>
>>>> _______________________________________________ keycloak-user
>>>> mailing list keycloak-user at lists.jboss.org
>>>> <mailto:keycloak-user at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>> -- Bill Burke JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________ keycloak-user
>>> mailing list keycloak-user at lists.jboss.org
>>> <mailto:keycloak-user at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>
> -- Bill Burke JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> ------------------------------
>
> _______________________________________________ keycloak-user
> mailing list keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> End of keycloak-user Digest, Vol 3, Issue 14
> ********************************************
>
>
>
>
> _______________________________________________ keycloak-user
> mailing list keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJTNSHcAAoJEDnJtskdmzLMHrYH/1D/vMgPxD0WUZ5KdIoD5Cow
gb9fa+RZDQrpPxL1qKpqWJX3g1cKt8hQa1Xz7dX64G3/xcLUUkoJKkAtiJPysp75
xbkdWV+RGQXDHuyZcS75xEXQlPaWt2cEVxdSXMalzfQPzVhq00FBbeJLirKLbYsY
I2CIjJgCSQhmOrVfP5vUSdrwsLsd+TBXee4779YiOceSW16oG9Nfsa5gF1XJSNhi
o2fZCEkoXhbTD7RXuhhrDWlFBCQOIgWf6FUHEAVKnXeIR5oey6U9hv1Z16Kd2Pll
Pv8+LWlJjKMfkmrCQrVQvYSI/n64vxjikta2ByBdOPethsebqXO9oknbiPtjq6E=
=TiWl
-----END PGP SIGNATURE-----
More information about the keycloak-user
mailing list