<div dir="ltr">I&#39;m pretty sure client templates are not the way to go here. Not even sure roles are the way to go.<div><br></div><div>What&#39;s does the uma_protection role do?</div><div>Why uma_authorization and kc_entitlement? What&#39;s the difference between the two?</div><div><br></div><div>Giving access to this information is that even something a user should be granting? Is it not an admin thing to do?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 June 2016 at 13:54, Pedro Igor Silva <span dir="ltr">&lt;<a href="mailto:psilva@redhat.com" target="_blank">psilva@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Marek,<br>
<br>
    When I define a role as default it is also added to the client &quot;Effective Roles&quot;, not only to users.<br>
<br>
    What I&#39;m doing right now is pretty much what you described, have some realm roles and add them to the scopes of a client template. I was just trying to avoid keeping these roles at the realm level and provide a default configuration where the roles are specific for a client. Which makes more sense.<br>
<br>
    Basically, I have three scopes:<br>
<br>
    * uma_protection, that should be mapped to client applications acting as resource servers, only.<br>
    * uma_authorization and kc_entitlement, that should be mapped to users as a client role for a given client app acting as a resource server. Ideally.<br>
<br>
    In an ideal world (for privacy reasons), when you try to access a protected resource that is protected with our authz stuff, the user must consent access to his authorization data. So you may have a consent page saying &quot;Third-party wants access to uma_authorization/kc_entitlement in Resource Server&quot;.<br>
<br>
    As I said, global roles can also be used here, but they are not specific to a client and may not represent clearly the scope of access the user is actually consenting.<br>
<br>
Thanks<br>
<span class="im HOEnZb"><br>
----- Original Message -----<br>
From: &quot;Marek Posolda&quot; &lt;<a href="mailto:mposolda@redhat.com">mposolda@redhat.com</a>&gt;<br>
To: &quot;Pedro Igor Silva&quot; &lt;<a href="mailto:psilva@redhat.com">psilva@redhat.com</a>&gt;, <a href="mailto:stian@redhat.com">stian@redhat.com</a><br>
Cc: &quot;keycloak-dev&quot; &lt;<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>&gt;<br>
</span><div class="HOEnZb"><div class="h5">Sent: Tuesday, June 14, 2016 6:18:32 AM<br>
Subject: Re: [keycloak-dev] Add roles to a client template<br>
<br>
Hey Pedro,<br>
<br>
the default roles are always automatically added to all newly created<br>
users. They are not added to scopes of newly created clients (clients<br>
have &quot;Full scope allowed&quot; by default anyway). To achieve something like<br>
default scope, you can maybe add the roles to scope of some client<br>
template and then add this client template to your client. The client<br>
will then inherit all scopes. Is it something you meant?<br>
<br>
Marek<br>
<br>
On 13/06/16 23:52, Pedro Igor Silva wrote:<br>
&gt; Btw, is there any way to specify the entity (client or user) to which a default role should be applied ?<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; From: &quot;Pedro Igor Silva&quot; &lt;<a href="mailto:psilva@redhat.com">psilva@redhat.com</a>&gt;<br>
&gt; To: <a href="mailto:stian@redhat.com">stian@redhat.com</a><br>
&gt; Cc: &quot;keycloak-dev&quot; &lt;<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>&gt;<br>
&gt; Sent: Monday, June 13, 2016 4:44:34 PM<br>
&gt; Subject: Re: [keycloak-dev] Add roles to a client template<br>
&gt;<br>
&gt; It is related with some simplifications to authz services configuration.<br>
&gt;<br>
&gt; In order to enable fine-grained authz, clients should be granted with specific roles to gain access to authz services. In some cases, users must consent access to his authorization data by third-party apps.<br>
&gt;<br>
&gt; When consenting access to his authorization data, the user is actually consenting to a third-party app access to the protected resources at a specific resource server. In this case, a client role can be used to specify just that. Eg.: on the consent page you&#39;ll see a &quot;uma_authorization in client-application-A&quot;<br>
&gt;<br>
&gt; I can also use realm roles to achieve the same result, but that would not be specific to a resource server/client-app. Although still a valid setup if the user wants so.<br>
&gt;<br>
&gt; What I want to do is just create a template with these roles. I was expecting that the template could help me to avoid creating and assigning these roles manually.<br>
&gt;<br>
&gt; This is not a blocker. As I said, realm roles can also be used to achieve the same results.<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; From: &quot;Stian Thorgersen&quot; &lt;<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>&gt;<br>
&gt; To: &quot;Pedro Igor Silva&quot; &lt;<a href="mailto:psilva@redhat.com">psilva@redhat.com</a>&gt;<br>
&gt; Cc: &quot;keycloak-dev&quot; &lt;<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>&gt;<br>
&gt; Sent: Monday, June 13, 2016 3:20:37 PM<br>
&gt; Subject: Re: [keycloak-dev] Add roles to a client template<br>
&gt;<br>
&gt; Client templates can only store roles and scope. Not sure it makes sense to<br>
&gt; add client roles, especially not since we&#39;re planning on introducing role<br>
&gt; namespaces in the future and that could conflict with the design around<br>
&gt; that.<br>
&gt;<br>
&gt; Can you elaborate on the use-case?<br>
&gt;<br>
&gt; On 13 June 2016 at 19:16, Pedro Igor Silva &lt;<a href="mailto:psilva@redhat.com">psilva@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Is it possible to add client roles to a client template ? Would like to<br>
&gt;&gt; provide a template with some default roles/scopes.<br>
&gt;&gt;<br>
&gt;&gt; Regards.<br>
&gt;&gt; Pedro Igor<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; keycloak-dev mailing list<br>
&gt;&gt; <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; keycloak-dev mailing list<br>
&gt; <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
&gt; _______________________________________________<br>
&gt; keycloak-dev mailing list<br>
&gt; <a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
<br>
</div></div></blockquote></div><br></div>