Token's issuedAt value is the same as value of NotBeforePolicy
by Michal Hajas
Hi,
I found out that when you do logout-all (in this step realm.notBefore value
is set) and subsequent login very quickly it may happen that Keycloak
returns tokens with an issuedAt value which is the same as the value of the
NotBeforePolicy.
Such tokens are considered invalid in adapter due to this check [1].
My question is, should we prevent such state? If yes what is correct
behavior?
1. Do not generate tokens with the same issuedAt value as NotBefore policy.
For example, in TokenManager [2] check NotBefore value and change
issuedAt for all tokens to (NotBefore + 1) in case they are same.
or
2. Change condition [2]:
.... && this.token.getIssuedAt() > deployment.getNotBefore();
to:
.... && this.token.getIssuedAt() >= deployment.getNotBefore();
The later will probably require to also check other non-java adapters
whether such check is present or not.
Best regards,
Michal
[1]
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-co...
[2]
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/o...
5 years, 8 months
Smaller RefreshTokens?
by Thomas Darimont
Hello,
the refresh tokens which are currently issued by Keycloak contain standard
JWT claims and references to the Keycloak session. Additionally they also
contain realm roles and client role information together with the used
scope.
I'm wondering whether roles and scope information is required for refresh
tokens or could even be removed?
Cheers,
Thomas
5 years, 8 months
Session management improvement
by yormen1＠gmail.com
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.
I apologies for the mistake earlier.
5 years, 8 months
Re: [keycloak-dev] Session management UI improvement
by yormen1＠gmail.com
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(a)lists.jboss.org wrote:
>
> Send keycloak-dev mailing list submissions to
> keycloak-dev(a)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(a)lists.jboss.org
>
> You can reach the person managing the list at
> keycloak-dev-owner(a)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(a)carretti.pro>
> Subject: Re: [keycloak-dev] Proposal: Improvements to
> IdpUsernamePasswordForm
> To: Marek Posolda <mposolda(a)redhat.com>, keycloak-dev
> <keycloak-dev(a)lists.jboss.org>
> Message-ID: <1554415195.6328.1.camel(a)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(a)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(a)redhat.com>
> Subject: Re: [keycloak-dev] Proposal: Improvements to
> IdpUsernamePasswordForm
> To: Dmitry Telegin <demetrio(a)carretti.pro>, keycloak-dev
> <keycloak-dev(a)lists.jboss.org>
> Message-ID: <2567518c-b341-27c9-b30d-8dd5fd5757a1(a)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(a)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(a)ericsson.com>
> Subject: [keycloak-dev] Few Admin events not getting raised
> To: "keycloak-dev(a)lists.jboss.org" <keycloak-dev(a)lists.jboss.org>
> Message-ID: <1554452469.17045.16.camel(a)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(a)ericsson.com>
> Subject: [keycloak-dev] Few Admin events not getting raised
> To: "keycloak-dev(a)lists.jboss.org" <keycloak-dev(a)lists.jboss.org>
> Message-ID: <1554452559.17045.17.camel(a)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(a)redhat.com>
> Subject: [keycloak-dev] Proposal: Approvals System
> To: keycloak-dev <keycloak-dev(a)lists.jboss.org>
> Message-ID:
> <CAMQSZygL8LGB80Won27vrGUh8s7MT0JjJWR-dfbjXifsR3mQ=w(a)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/approva...
>
> 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(a)redhat.com>
> Subject: Re: [keycloak-dev] Few Admin events not getting raised
> To: Shiva Prasad Thagadur Prakash
> <shiva.prasad.thagadur.prakash(a)ericsson.com>,
> "keycloak-dev(a)lists.jboss.org" <keycloak-dev(a)lists.jboss.org>
> Message-ID: <7745f1a9-cd9c-489d-169b-cfabe5697db4(a)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(a)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
>
> End of keycloak-dev Digest, Vol 70, Issue 8
> *******************************************
5 years, 8 months
Few Admin events not getting raised
by Shiva Prasad Thagadur Prakash
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
5 years, 8 months
Proposal: Approvals System
by Václav Muzikář
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/approva...
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.
5 years, 8 months
Few Admin events not getting raised
by Shiva Prasad Thagadur Prakash
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
5 years, 8 months
Keycloak demo
by Micha Preußer
Hey there,
this is not really a development question (not yet), but I think
somebody can help me out here.
In the latest (5.0.0) documentation for server development, you
have the topic 8.3. Authenticator SPI Walk Through. There you can find
an example for third auth plugins, but the latest "demo distribution",
which contains this example, could I found for the version 4.3.0.
Is there any newer version, I didn't found or how can I go on to take a
look at this example and deploy it?
Thanks a lot.
Micha Preußer
5 years, 8 months
Keycloak session limiting (KEYCLOAK-849) (BA-93)
by Mauro de Wit
Hello,
I am sending this e-mail because I have some questions regarding the
enhancement request that enables configurable session limiting in Keycloak
as discussed here:
https://issues.jboss.org/browse/KEYCLOAK-849 (The developer that Marc Wijma
referred to in his comment as being available for this task is me btw :))
In the comments a solution is proposed that makes use of a custom
Authenticator that is dropped into the authentication flow where it can be
configured. While I can see the benefit of leveraging the existing
components as much as possible (including the configuration options in that
flow), I am wondering if this is the best solution. As far as I can tell,
this component is not performing any authentication at all. Moreover this
functionality operates 'above' the authentication mechanisms and should
apply to all of them.
So is an Authenticator really the desired place to implement this? Or is
this just the quickest route, while not being the most desirable option for
the long term? What would be an alternative approach be? That would place
this implementation and configuration in the existing Session configuration
code for instance.
I just now started investigating this task and looking into the options
that would meet our requirements. Hope to hear from you.
Regards
Mauro
>
5 years, 9 months
