<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 11 July 2016 at 09:35, Marek Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@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">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 11/07/16 08:22, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On 8 July 2016 at 14:07, Marek
            Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@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">
              <div bgcolor="#FFFFFF" text="#000000"><span>
                  <div>On 07/07/16 12:07, Stian Thorgersen wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr"><br>
                      <div class="gmail_extra"><br>
                        <div class="gmail_quote">On 7 July 2016 at
                          09:45, Marek Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank"></a><a href="mailto:mposolda@redhat.com" target="_blank">mposolda@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">
                            <div bgcolor="#FFFFFF" text="#000000"><span>
                                <div>On 04/07/16 09:47, Stian Thorgersen
                                  wrote:<br>
                                </div>
                                <blockquote type="cite">
                                  <div dir="ltr"><span style="font-size:12.8px">ScopeAggregatorProtocolMapper


                                      sounds interesting, but I&#39;m not
                                      quite sure how it would look like
                                      to an end-user. </span>
                                    <div><span style="font-size:12.8px"><br>
                                      </span></div>
                                    <div><span style="font-size:12.8px">*
                                        Are these managed on a separate
                                        screen or on the protocol
                                        mappers screen? <br>
                                      </span></div>
                                  </div>
                                </blockquote>
                              </span> I am thinking about the
                              protocolMappers screen. Just add another
                              &quot;type&quot; of protocolMapper. This means that
                              we don&#39;t need to add another
                              concept/modelType just for scope
                              parameter, but still we can easily
                              filter/view the available mappers of type
                              &#39;scope aggregator&#39; (on the screen with
                              list of all protocolMappers).</div>
                          </blockquote>
                          <div><br>
                          </div>
                          <div>Not quite sure I see why it should be on
                            the protocol mappers screen. As it&#39;s a
                            separate type of mapper as well the UI to
                            define them would be different I&#39;m not sure
                            I see why it can&#39;t be a separate screen.</div>
                          <div><br>
                          </div>
                          <div>I think it would fit better on the scope
                            tab. It could have two tabs &quot;Default scope&quot;
                            and &quot;Scopes&quot; or something like that.</div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span> Not sure which place is better. However I am
                maybe slightly more for protocolMappers screen because:<br>
                <br>
                - It just looks a bit more intuitive to me if all the
                things, which are represented at model/DB level by
                protocolMapper entity are also in admin console grouped
                together on single place. But maybe it&#39;s just me <span><span>
                    ;-) </span></span></div>
            </blockquote>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><br>
                <br>
                - For the aggregated mapper, you can select that
                &quot;children&quot; mappers will be either simple mappers or
                other aggregated mappers. For example for the
                &quot;full-profile&quot; mapper, you can select that it&#39;s child is
                another aggregated mapper &quot;profile&quot; together with some
                additional simple mappers like &quot;first_name&quot; or
                &quot;last_name&quot; . Hence in the list of available mappers,
                you should be able to see both simple and aggregated
                mappers. <br>
                Isn&#39;t it then a bit confusing that you will see both the
                simple mappers like &quot;firstName&quot; (which are configured in
                &quot;mappers&quot; tab) together with aggregated mappers like
                &quot;profile&quot; (which are configured under &quot;scope/default
                scope&quot; tab) together?<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>You lost me a bit here. I think I may have miss
              understood something you explained before.</div>
            <div><br>
            </div>
            <div>My assumption was that there are two separate things:
              regular mappers and scope mappers. Regular mappers are
              configured as before, while scope mappers are configured
              for each scope. So there would be separate screens in
              either case. Maybe I&#39;m wrong here, but I could see a page
              that lists all scopes, then you can click on the scope to
              see what mappers are applied as well as what roles are
              applied.</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    I was thinking about ScopeAggregatedMapper just like about another
    implementation of ProtocolMapper interface. No another special model
    or special mapper type, which Keycloak needs to deal with. The
    Keycloak (TokenManager) will treat like any other mapper, so will
    just call &quot;transformAccessToken&quot; to it and ScopeAggregatedMapper
    impl will delegate to other children mappers and apply roles.<br>
    <br>
    The difference is, that UI will need to be a bit special then for
    other mappers. There is possibility that we will add the support
    showing list of roles and protocolMappers to the directive
    &quot;kc-provider-config&quot; . However it looks the better option might be
    that particular protocolMapper implementation (or particular
    provider implementation in general) has a way to override the
    angular template with it&#39;s own UI if it wants to do it.<br>
    <br>
    For example, if there is protocolMapper provider with id &quot;foo&quot; then
    angular will:<br>
    - First look if there is special screen
    &quot;protocol-mapper-detail_foo.html&quot; .<br>
    - If the screen doesn&#39;t exist, it will fallback to default
    &quot;protocol-mapper-detail.html&quot; screen with the &quot;kc-provider-config&quot;
    directive for generic properties.<br>
    <br>
    For the protocolMapper, the scopeAggregatedMapper will have special
    screen &quot;protocol-mapper-detail_scope-aggregate.html&quot; when all other
    impls just use the generic screen like now. <span style="color:#000080;background-color:#e4e4ff;font-weight:bold"><br>
    </span><span class="">
    
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>Maybe it&#39;s time to do some mock screens or wire frames?</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    +1<br>
    <br>
    or start prototyping and see how it goes? :)</div></blockquote><div><br></div><div>Prototyping is just a superior mock ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font color="#888888"><br>
    <br>
    Marek</font></span><div><div class="h5"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> <br>
                <br>
                Btv. Our current providerModel classes usually have
                something like:<br>
                <br>
                Map&lt;String, String&gt; config;<br>
                <br>
                on them. However for the aggregated mapper impl, it may
                be needed to extend this to:<br>
                <br>
                Map&lt;String, List&lt;String&gt;&gt; config; <br>
                <br>
                as mapper will need to have the property with the list
                of children mappers and property with the list of
                children roles. The question is, how to represent it in
                DB? I can see possibilities like:<br>
                a) The value at DB level will be just simple string with
                children values divided by some delimiter (eg.
                &quot;mapper123###mapper456###mapper789&quot; )<br>
                b) The value will be list at DB level with separate
                record for every value (eg. 3 values like &quot;mapper123&quot; ,
                &quot;mapper456&quot; , &quot;mapper789&quot; )<br>
                <br>
                It seems the (b) is a bit harder for migration, but
                likely the more proper way to address this? It looks
                like something to keep in mind once we refactor to the
                &quot;unified&quot; providerModel table.<span><br>
                  <br>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div class="gmail_extra">
                        <div class="gmail_quote">
                          <div> </div>
                          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                            <div bgcolor="#FFFFFF" text="#000000"><span><br>
                                <blockquote type="cite">
                                  <div dir="ltr">
                                    <div><span style="font-size:12.8px">*
                                        How do users define and view
                                        scopes, including viewing what
                                        claims/mappers/roles are
                                        associated with a scope?</span></div>
                                    <div><span style="font-size:12.8px">*
                                        How does a user add/remove
                                        claims, protocol mappers and
                                        roles to
                                        a ScopeAggregatorProtocolMapper?
                                      </span><br>
                                    </div>
                                  </div>
                                </blockquote>
                              </span> I am thinking that for roles, you
                              will select the roles in same way, like
                              it&#39;s in current &quot;Scopes&quot; tab of client (or
                              &quot;role mappings&quot; tab of user). Probably
                              very similar UI can be used for selecting
                              &quot;children&quot; mappers of current
                              protocolMapper though? Something like
                              &quot;Available mappers&quot; and &quot;Assigned mappers&quot;
                              and buttons like &quot;Add selected&quot; and
                              &quot;Remove selected&quot;. Also similarly like for
                              roles, you can view in &quot;Effective mappers&quot;
                              the list of all effective mappers in case
                              that you have more composed aggregated
                              scopeAggregatorMappers.<br>
                              <br>
                              For example, if you have mapper for scope
                              parameter &quot;full-profile&quot;, which will have
                              children mappers, that will point to other
                              scope aggregated mappers : &quot;profile&quot; ,
                              &quot;email&quot; and &quot;phone&quot;. Hence in &quot;Effective
                              mappers&quot; for &quot;full-profile&quot; you will see
                              all the descendants, not just the direct
                              children. So you will see also all the
                              simple attribute mappers like &quot;firstName&quot;,
                              &quot;lastName&quot;, &quot;birthday&quot;, &quot;phone number&quot;,
                              ...</div>
                          </blockquote>
                          <div><br>
                          </div>
                          <div>Sounds good</div>
                          <div> </div>
                          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                            <div bgcolor="#FFFFFF" text="#000000"><span><br>
                                <blockquote type="cite">
                                  <div dir="ltr">
                                    <div><span style="font-size:12.8px">*
                                        Do we provide one or more
                                        built-in </span><span style="font-size:12.8px">ScopeAggregatorProtocolMapper


                                        that are configurable? I assume
                                        so and that users don&#39;t have to
                                        programatically define scopes.</span></div>
                                  </div>
                                </blockquote>
                              </span> Yes. I think that we should
                              provide those built-in, which are
                              specified by OIDC specification. Which is
                              &quot;profile&quot; , &quot;email&quot; , &quot;phone&quot; , &quot;address&quot;.
                              And we will need to define mappers for all
                              their simple attributes ( &quot;birthday&quot;,
                              &quot;gender&quot; , ...) . Those simple mappers
                              like &quot;birthday&quot; won&#39;t be root mappers by
                              default, so they won&#39;t be applied unless
                              the scope parameter is used (for their
                              parent scopeAggregatorMapper).<br>
                              <br>
                              For backwards compatibility, we will still
                              use the same &#39;simple&#39; mappers like now (
                              username, email, full name, family name,
                              given name) and they will be added to
                              token by default. The scopeAggregator
                              mappers (and their corresponding children)
                              will be applied just if the scope
                              parameter with corresponding value will be
                              used.</div>
                          </blockquote>
                          <div><br>
                          </div>
                          <div>SAML doesn&#39;t have this concept does it?
                            If so it probably doesn&#39;t even make sense to
                            show scope mappers for SAML clients.</div>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                </span> I don&#39;t think that SAML has something like scope
                parameter. At least I am not aware of that <span><span>
                    :-) </span></span><br>
                <br>
                However our SAML clients currently have &quot;Scope&quot; tab
                visible to map which realm roles (or client roles) are
                allowed to be put into SAML assertion. That works same
                like for OIDC clients and makes sense to keep. I guess
                you meant to hide just the new sub-tab of the &quot;Scope&quot;
                tab for configure scope parameter?<span><font color="#888888"><br>
                    <br>
                    Marek</font></span>
                <div>
                  <div><br>
                    <blockquote type="cite">
                      <div dir="ltr">
                        <div class="gmail_extra">
                          <div class="gmail_quote">
                            <div> </div>
                            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                              <div bgcolor="#FFFFFF" text="#000000"> </div>
                            </blockquote>
                            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                              <div bgcolor="#FFFFFF" text="#000000"><span><br>
                                  <blockquote type="cite">
                                    <div dir="ltr">
                                      <div><span style="font-size:12.8px">* Can
                                          a scope resolve to
                                          multiple ScopeAggregatorProtocolMapper?</span></div>
                                    </div>
                                  </blockquote>
                                </span> Yes (see above)<span><font color="#888888"><br>
                                    <br>
                                    Marek</font></span>
                                <div>
                                  <div><br>
                                    <blockquote type="cite">
                                      <div class="gmail_extra"><br>
                                        <div class="gmail_quote">On 1
                                          July 2016 at 21:45, Marek
                                          Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank"></a><a href="mailto:mposolda@redhat.com" target="_blank">mposolda@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">Ok,
                                            I wasn&#39;t also 100% keen
                                            about using role.<br>
                                            <br>
                                            Thinking also about what
                                            Pedro mentioned before about
                                            protocol mappers. So I
                                            wonder that instead of
                                            introduce new &quot;scope&quot;
                                            concept, we just reuse
                                            protocolMappers SPI and have
                                            special impl of
                                            protocolMapper, which is
                                            able to deal with scope
                                            parameter and aggregate
                                            other &quot;children&quot;
                                            protocolMappers and roles?<br>
                                            <br>
                                            Something like this:<br>
                                            - There will be new
                                            ProtocolMapper
                                            implementation like
                                            ScopeAggregatorProtocolMapper. 
                                            You will define value of
                                            scope parameter (eg. &quot;photo&quot;
                                            ) in the configuration of
                                            this protocolMapper. Mapper
                                            will be ignored if scope
                                            parameter value with this
                                            name was not used.<br>
                                            <br>
                                            - You will be able to define
                                            &quot;children&quot; protocolMappers
                                            and &quot;children&quot; roles in
                                            ScopeAggregatorProtocolMapper.<br>
                                            <br>
                                            - For each client (and
                                            clientTemplate), we will
                                            have many defined
                                            protocolMappers, but just
                                            some subset of them are
                                            &quot;root&quot; mappers, which are
                                            applied by default. The rest
                                            of mappers will be used just
                                            as &quot;children&quot; of root
                                            mappers. So in client model,
                                            we might have:<br>
                                            client.getDefinedProtocolMappers()
                                            // all defined<br>
                                            client.getProtocolMappers() 
                                              // just subset of defined
                                            (defacto root mappers)<br>
                                            <br>
                                            - For example: client will
                                            have defined
                                            protocolMappers: firstName,
                                            lastName, birthday, profile,
                                            email. Just &quot;profile&quot; and
                                            &quot;email&quot; will be root
                                            mappers. And &quot;profile&quot; is
                                            ScopeAggregatorMapper for
                                            scope value &quot;profile&quot; and
                                            it&#39;s children mappers are :
                                            firstName, lastName,
                                            birthday.<br>
                                            <br>
                                            So then:<br>
                                            -- user will send
                                            &quot;scope=profile&quot; . Then
                                            defacto all of &quot;firstName&quot;,
                                            &quot;lastName&quot;, &quot;birthday&quot;,
                                            &quot;email&quot; claims will be
                                            included in token. On
                                            consent screen will be just
                                            &quot;Profile&quot; and &quot;Email&quot;<br>
                                            -- user won&#39;t send
                                            &quot;scope=profile&quot; . Then
                                            defacto just &quot;email&quot; claim
                                            will be included (So for
                                            this example, email is
                                            always included even if not
                                            specified by scope
                                            parameter).<br>
                                            <br>
                                            - With this concept, we are
                                            able to aggregate many
                                            various claims into single
                                            value of &quot;scope&quot; and on the
                                            consent screen have just the
                                            roots. This would fit well
                                            for the default scope values
                                            mentioned by OIDC specs. We
                                            are also able to define
                                            mappers (claims), which will
                                            be always available even if
                                            not specified by scope
                                            parameter.<br>
                                            <br>
                                            - For the roles, I am not
                                            100% sure whether to include
                                            them into the concept or
                                            not? However it seems to me
                                            that rather yes. The
                                            particular role will be
                                            applied into token just if
                                            all of those 3 conditions
                                            are met:<br>
                                            1) user is member of the
                                            role<br>
                                            2) client has scope for the
                                            role (so current &quot;scope&quot; tab
                                            in clients will remain as
                                            is)<br>
                                            3) if role has
                                            scopePAramRequired=true,
                                            then it must be included in
                                            some mapper (in other words,
                                            those roles are not included
                                            directly in
                                            clientSession.getRoles , but
                                            it&#39;s the responsibility of
                                            ScopeAggregatorProtocolMapper
                                            to add them into token if
                                            conditions 1+2 are met).<br>
                                            <br>
                                            So again, user won&#39;t see all
                                            children roles on consent
                                            screen. Just the parent
                                            protocolMapper.<br>
                                            <br>
                                            This will work fine with
                                            &quot;scope=offline_access&quot; .
                                            There will be protocolMapper
                                            for &quot;offline_access&quot;
                                            parameter, which will
                                            aggregate just one children
                                            role (the current realm role
                                            &quot;offline_access&quot;). The
                                            offline token will be issued
                                            just if accessToken will
                                            have &quot;offline_access&quot;
                                            permission. So if some
                                            client, doesn&#39;t need offline
                                            tokens, it can just remove
                                            &quot;offline_access&quot;
                                            protocolMapper. Also if some
                                            user shouldn&#39;t be allowed to
                                            request offline tokens,
                                            admin can remove him from
                                            the &quot;offline_access&quot; role.<br>
                                            <br>
                                            - If some scope parameter is
                                            applicable for more clients,
                                            it can be defined on
                                            clientTemplate.<br>
                                            <br>
                                            <br>
                                            PS: I will be on holidays
                                            and back on next Thursday
                                            7th July. So sorry if I
                                            won&#39;t reply immediately to
                                            next mails.<br>
                                            <br>
                                            Mare
                                            <div>
                                              <div><br>
                                                <br>
                                                <br>
                                                On 01/07/16 14:57, Pedro
                                                Igor Silva wrote:<br>
                                                <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                                                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                                                    Reading all of this
                                                    makes me think it
                                                    would be cleaner to
                                                    introduce a<br>
                                                    separate scope
                                                    concept ;)<br>
                                                    <br>
                                                    A user doesn&#39;t have
                                                    a scope - a user has
                                                    roles and
                                                    attributes. Re-using
                                                    roles<br>
                                                    concept for the
                                                    scope just makes it
                                                    feel awkward and
                                                    retrofitted.<br>
                                                  </blockquote>
                                                  +10000<br>
                                                </blockquote>
                                                <br>
                                              </div>
                                            </div>
                                          </blockquote>
                                        </div>
                                        <br>
                                      </div>
                                    </blockquote>
                                    <br>
                                  </div>
                                </div>
                              </div>
                            </blockquote>
                          </div>
                          <br>
                        </div>
                      </div>
                    </blockquote>
                    <br>
                  </div>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div></div>