[keycloak-dev] Session management UI improvement
yormen1 at gmail.com
yormen1 at gmail.com
Fri Apr 5 16:49:56 EDT 2019
I don't know if something could be done about multiple selection when you want to logout a group of session out from keycloak at the same time.
> On Apr 5, 2019, at 1:57 PM, keycloak-dev-request at lists.jboss.org wrote:
>
> Send keycloak-dev mailing list submissions to
> keycloak-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> or, via email, send a message with subject or body 'help' to
> keycloak-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> keycloak-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of keycloak-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Proposal: Improvements to IdpUsernamePasswordForm
> (Dmitry Telegin)
> 2. Re: Proposal: Improvements to IdpUsernamePasswordForm
> (Marek Posolda)
> 3. Few Admin events not getting raised
> (Shiva Prasad Thagadur Prakash)
> 4. Few Admin events not getting raised
> (Shiva Prasad Thagadur Prakash)
> 5. Proposal: Approvals System (V?clav Muzik??)
> 6. Re: Few Admin events not getting raised (Marek Posolda)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 05 Apr 2019 00:59:55 +0300
> From: Dmitry Telegin <demetrio at carretti.pro>
> Subject: Re: [keycloak-dev] Proposal: Improvements to
> IdpUsernamePasswordForm
> To: Marek Posolda <mposolda at redhat.com>, keycloak-dev
> <keycloak-dev at lists.jboss.org>
> Message-ID: <1554415195.6328.1.camel at carretti.pro>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Marek,
>
>> On Thu, 2019-04-04 at 09:14 +0200, Marek Posolda wrote:
>> Hi Dmitry,
>>
>>> On 04/04/2019 00:45, Dmitry Telegin wrote:
>>> Hi Marek,
>>>
>>> You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
>>> - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons
>>
>> You're right. Small addition: The IdpUsernamePasswordForm displays?
>> social buttons, but just of those identity providers, which are already?
>> linked to specified user. In other words, if you want to link your?
>> account to broker-A and your account is already linked to broker-B, then?
>> broker-B is displayed on the form. This way, you have possibility to?
>> re-authenticate not just with your password, but alternatively by login?
>> to already linked broker-B, which is already linked to your account and?
>> hence "trusted" to be used for prove your identity.
>>
>> It seems that with your proposal in case that username is unknown, we?
>> won't display any brokers on the screen and hence it will be mandatory?
>> to do re-authentication by username+password?
>
> Yes, that's correct.
>
>>
>>> - IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:
>>>
>>> federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}
>>>
>>> So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).
>>
>> I suggest to update IdpUsernamePasswordForm authenticator. In case that?
>> EXISTING_USER_INFO is not there, we can do the behaviour like:
>>
>> - User will need to provide both username+password. Hence username field?
>> will need to be enabled
>> - Social buttons won't be displayed on the login screen
>> - Message will be bit different. For example just: Authenticate to link?
>> your account with {1}
>>
>> For the case when EXISTING_USER_INFO is available, I would like to keep?
>> the same behaviour as currently is.
>>
>> WDYT?
>
> This is exactly how I was planning to do it myself :) so if you greenlight this, I'll proceed with JIRA/PR.
>
> Just FYI, I'm also planning to publish a "standalone" version of the authenticator to be used with Keycloak <= 5.0.0.
>
> Dmitry
>
>>
>> Marek
>>
>>>
>>> Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.
>>>
>>> Thanks!
>>> Dmitry
>>>
>>>> On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
>>>>> On 28/03/2019 17:06, Dmitry Telegin wrote:
>>>>> Hi,
>>>>>
>>>>> I'm currently working to implement the following requirements:
>>>>> - users are managed externally via LDAP, self-registrations disabled;
>>>>> - there is an external IdP;
>>>>> - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
>>>>> - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
>>>>>
>>>>> Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
>>>>> However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
>>>>>
>>>>> My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
>>>>
>>>> I wonder if you can't already achieve something like this with the OOTB
>>>> authenticator implementations, but just correctly configure them? For
>>>> example in the "First Broker Login" flow used for your identity
>>>> provider, you can just directly use the default browser-based
>>>> authenticator ( UsernamePasswordForm ) instead of the
>>>> IdpUsernamePasswordForm. That way, the username+password form will be
>>>> always shown for "First Broker Login" and once user authenticates, his
>>>> account will be linked with IdP account.
>>>>
>>>> Marek
>>>>
>>>>> Please let me know if you think it's worth having this in Keycloak. Regards,
>>>>> Dmitry
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 5 Apr 2019 08:07:14 +0200
> From: Marek Posolda <mposolda at redhat.com>
> Subject: Re: [keycloak-dev] Proposal: Improvements to
> IdpUsernamePasswordForm
> To: Dmitry Telegin <demetrio at carretti.pro>, keycloak-dev
> <keycloak-dev at lists.jboss.org>
> Message-ID: <2567518c-b341-27c9-b30d-8dd5fd5757a1 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>> On 04/04/2019 23:59, Dmitry Telegin wrote:
>> Hi Marek,
>>
>>> On Thu, 2019-04-04 at 09:14 +0200, Marek Posolda wrote:
>>> Hi Dmitry,
>>>
>>>> On 04/04/2019 00:45, Dmitry Telegin wrote:
>>>> Hi Marek,
>>>>
>>>> You absolutely right, UsernamePasswordForm does the trick. However, the login screen rendered by?UsernamePasswordForm is different from that of IdpUsernamePasswordForm in the following aspects:
>>>> - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons
>>> You're right. Small addition: The IdpUsernamePasswordForm displays
>>> social buttons, but just of those identity providers, which are already
>>> linked to specified user. In other words, if you want to link your
>>> account to broker-A and your account is already linked to broker-B, then
>>> broker-B is displayed on the form. This way, you have possibility to
>>> re-authenticate not just with your password, but alternatively by login
>>> to already linked broker-B, which is already linked to your account and
>>> hence "trusted" to be used for prove your identity.
>>>
>>> It seems that with your proposal in case that username is unknown, we
>>> won't display any brokers on the screen and hence it will be mandatory
>>> to do re-authentication by username+password?
>> Yes, that's correct.
>>
>>>> - IdpUsernamePasswordForm renders the message relevant to IdP-linking-by-reauthentication, which is this:
>>>>
>>>> federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your account with {1}
>>>>
>>>> So, my requirement is to implement the appearance of IdpUsernamePasswordForm + behavior of UsernamePasswordForm. I think this could be done either by augmenting the former, or by merging the two authenticators into a unified one, that would exhibit different behavior depending on the context (normal login vs. reauthentication for IdP linking).
>>> I suggest to update IdpUsernamePasswordForm authenticator. In case that
>>> EXISTING_USER_INFO is not there, we can do the behaviour like:
>>>
>>> - User will need to provide both username+password. Hence username field
>>> will need to be enabled
>>> - Social buttons won't be displayed on the login screen
>>> - Message will be bit different. For example just: Authenticate to link
>>> your account with {1}
>>>
>>> For the case when EXISTING_USER_INFO is available, I would like to keep
>>> the same behaviour as currently is.
>>>
>>> WDYT?
>> This is exactly how I was planning to do it myself :) so if you greenlight this, I'll proceed with JIRA/PR.
>
> +1
>
> Marek
>
>>
>> Just FYI, I'm also planning to publish a "standalone" version of the authenticator to be used with Keycloak <= 5.0.0.
>>
>> Dmitry
>>
>>> Marek
>>>
>>>> Please let me know which way seems better for you, with the idea in mind of having this contributed to upstream.
>>>>
>>>> Thanks!
>>>> Dmitry
>>>>
>>>>> On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
>>>>>> On 28/03/2019 17:06, Dmitry Telegin wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm currently working to implement the following requirements:
>>>>>> - users are managed externally via LDAP, self-registrations disabled;
>>>>>> - there is an external IdP;
>>>>>> - generally, there is no way to automatically match IdP identity with Keycloak's one, so IdP linking will always be performed by the user manually;
>>>>>> - in order to do that, the user should click the IdP icon in the login screen, authenticate with the IdP, get back to Keycloak and "claim" his/her Keycloak account by entering correct username and password.
>>>>>>
>>>>>> Currently, the closest thing in Keycloak is o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka "idp-username-password-form", aka "Username Password Form for identity provider reauthentication").
>>>>>> However, it 1) prefills username field and makes it non-editable, 2) depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing user model (EXISTING_USER_INFO auth note).
>>>>>>
>>>>>> My proposal is to improve IdpUsernamePasswordForm by allowing its execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter username.
>>>>> I wonder if you can't already achieve something like this with the OOTB
>>>>> authenticator implementations, but just correctly configure them? For
>>>>> example in the "First Broker Login" flow used for your identity
>>>>> provider, you can just directly use the default browser-based
>>>>> authenticator ( UsernamePasswordForm ) instead of the
>>>>> IdpUsernamePasswordForm. That way, the username+password form will be
>>>>> always shown for "First Broker Login" and once user authenticates, his
>>>>> account will be linked with IdP account.
>>>>>
>>>>> Marek
>>>>>
>>>>>> Please let me know if you think it's worth having this in Keycloak. Regards,
>>>>>> Dmitry
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 5 Apr 2019 08:21:10 +0000
> From: Shiva Prasad Thagadur Prakash
> <shiva.prasad.thagadur.prakash at ericsson.com>
> Subject: [keycloak-dev] Few Admin events not getting raised
> To: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
> Message-ID: <1554452469.17045.16.camel at ericsson.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Guys,
>
> We see that few admin events are not getting logged to syslog/logfile.
> Creating scope, Creating New policy for a client and Creating new
> permission for a client. COuld anyone please help us?
>
> Steps to reproduce:
> New permisson event
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
> based
> ? ? 4. Create New permission
>
> Failed Symptoms: No any events generated.
>
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ????Go to clients->clientName->Authorization ->Policies - Create
> POlicy??-> Role
> ? ? 3. Create New policy
>
> Failed Symptoms: No any events generated.
>
>
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
> ? ? 4. Create New scope event_scope
> Failed Symptoms:?No any events generated.
>
> Thanks & regards,
> Shiva
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 5 Apr 2019 08:22:39 +0000
> From: Shiva Prasad Thagadur Prakash
> <shiva.prasad.thagadur.prakash at ericsson.com>
> Subject: [keycloak-dev] Few Admin events not getting raised
> To: "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
> Message-ID: <1554452559.17045.17.camel at ericsson.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Guys,
>
> We see that few admin events are not getting logged to syslog/logfile.
> Creating scope, Creating New policy for a client and Creating new
> permission for a client. COuld anyone please help us?
>
> Steps to reproduce:
> New permisson event
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
> based
> ? ? 4. Create New permission
>
> Failed Symptoms: No any events generated.
>
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ????Go to clients->clientName->Authorization ->Policies - Create
> POlicy??-> Role
> ? ? 3. Create New policy
>
> Failed Symptoms: No any events generated.
>
>
> ? ? 1. Create new client f.i. in master realm
> ? ? 2. Set "Authorization Enabled"
> ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
> ? ? 4. Create New scope event_scope
> Failed Symptoms:?No any events generated.
>
> Thanks & regards,
> Shiva
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 5 Apr 2019 12:19:19 +0200
> From: V?clav Muzik?? <vmuzikar at redhat.com>
> Subject: [keycloak-dev] Proposal: Approvals System
> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> Message-ID:
> <CAMQSZygL8LGB80Won27vrGUh8s7MT0JjJWR-dfbjXifsR3mQ=w at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hello,
>
> I've been working on an Approvals System for Keycloak and I'd like to
> discuss the design proposal.
>
> In short, it's a system that is responsible for audit, interception and
> approving/rejection of configuration changes in Keycloak. Even though it's
> designed as general as possible (i.e. able to intercept just about any
> config change), the initial scope will be probably focused on users
> operations.
>
> It's currently in a PoC state with a formalized design proposal available:
> https://github.com/keycloak/keycloak-community/blob/master/design/approvals-system.md
>
> Please let me know your thoughts.
>
> Thank you.
>
> Regards,
> V?clav Muzik??
>
> --
> V?clav Muzik??
> Senior Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 5 Apr 2019 15:55:49 +0200
> From: Marek Posolda <mposolda at redhat.com>
> Subject: Re: [keycloak-dev] Few Admin events not getting raised
> To: Shiva Prasad Thagadur Prakash
> <shiva.prasad.thagadur.prakash at ericsson.com>,
> "keycloak-dev at lists.jboss.org" <keycloak-dev at lists.jboss.org>
> Message-ID: <7745f1a9-cd9c-489d-169b-cfabe5697db4 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Looks like a bug. Feel free to create JIRA. If you're able to send PR
> with the fix, it will be even better and will cause that bug will be
> fixed faster :)
>
> Thanks,
> Marek
>
>> On 05/04/2019 10:22, Shiva Prasad Thagadur Prakash wrote:
>> Hi Guys,
>>
>> We see that few admin events are not getting logged to syslog/logfile.
>> Creating scope, Creating New policy for a client and Creating new
>> permission for a client. COuld anyone please help us?
>>
>> Steps to reproduce:
>> New permisson event
>> ? ? 1. Create new client f.i. in master realm
>> ? ? 2. Set "Authorization Enabled"
>> ? ? 3. Go to clients->clientName->Authorization ->Permissions - Scope
>> based
>> ? ? 4. Create New permission
>>
>> Failed Symptoms: No any events generated.
>>
>> ? ? 1. Create new client f.i. in master realm
>> ? ? 2. Set "Authorization Enabled"
>> ????Go to clients->clientName->Authorization ->Policies - Create
>> POlicy??-> Role
>> ? ? 3. Create New policy
>>
>> Failed Symptoms: No any events generated.
>>
>>
>> ? ? 1. Create new client f.i. in master realm
>> ? ? 2. Set "Authorization Enabled"
>> ? ? 3. Go to clients->clientName->Authorization ->Authorization Scopes
>> ? ? 4. Create New scope event_scope
>> Failed Symptoms:?No any events generated.
>>
>> Thanks & regards,
>> Shiva
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> ------------------------------
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> End of keycloak-dev Digest, Vol 70, Issue 8
> *******************************************
More information about the keycloak-dev
mailing list