Hi Farasath,
On Thu, Apr 25, 2019 at 9:26 AM Farasath Ahamed wrote:
>
>
> On Thu, Apr 25, 2019 at 7:32 AM Johann Nallathamby
> wrote:
>
>> Hi Malithi,
>>
>> On Thu, Apr 25, 2019 at 12:34 AM Malithi Edirisinghe
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby
>>>
Hi All,
Can we create a *virtual* user by the authentication valve. This *virtual*
user is not persisted in any user store, and not federated. We use a UUID
as the user ID.
This user is not a real user, but represent the "access token", its scopes,
etc.
Then we would have a *virtual* user store,
On Thu, Apr 25, 2019 at 7:32 AM Johann Nallathamby wrote:
> Hi Malithi,
>
> On Thu, Apr 25, 2019 at 12:34 AM Malithi Edirisinghe
> wrote:
>
>>
>>
>> On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby
>> wrote:
>>
>>> First of all, I don't understand what is the design issue with using
>>>
Hi Malithi,
On Thu, Apr 25, 2019 at 12:34 AM Malithi Edirisinghe
wrote:
>
>
> On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby
> wrote:
>
>> First of all, I don't understand what is the design issue with using
>> OAuth2 as a handler in authenticating and authorizing access to Rest APIs
>>
On Wed, Apr 24, 2019 at 11:13 PM Johann Nallathamby wrote:
> First of all, I don't understand what is the design issue with using
> OAuth2 as a handler in authenticating and authorizing access to Rest APIs
> by a client? Isn't that what OAuth2 is meant for typically?
>
Why should an access
First of all, I don't understand what is the design issue with using OAuth2
as a handler in authenticating and authorizing access to Rest APIs by a
client? Isn't that what OAuth2 is meant for typically?
Secondly, I think if the use case contains secondary user stores and client
expects to call
On Wed, Apr 24, 2019 at 4:42 PM Ruwan Abeykoon wrote:
> Hi All,
> Is that mean we use the same token to authentication(of the app) and
> authorization (for the resource), both?
>
Well actually the case is, we have implemented a mechanism to allow access
for resources (REST APIs) with an OAuth2
Hi All,
Is that mean we use the same token to authentication(of the app) and
authorization (for the resource), both?
Cheers,
Ruwan A
On Wed, Apr 24, 2019 at 1:49 PM Malithi Edirisinghe
wrote:
>
>
> On Wed, Apr 24, 2019 at 1:31 PM Farasath Ahamed
> wrote:
>
>>
>>
>> On Wed, Apr 24, 2019 at
On Wed, Apr 24, 2019 at 1:31 PM Farasath Ahamed wrote:
>
>
> On Wed, Apr 24, 2019 at 1:23 PM Malithi Edirisinghe
> wrote:
>
>> Hi All,
>>
>> Yes, the major problem here is using an oauth token to get the user realm
>> and using it later for authorization.
>> OAuth is for authorization, in that
On Wed, Apr 24, 2019 at 1:23 PM Malithi Edirisinghe
wrote:
> Hi All,
>
> Yes, the major problem here is using an oauth token to get the user realm
> and using it later for authorization.
> OAuth is for authorization, in that aspect IMO, we need to re-design this
> handler.
>
> However, to come
Hi All,
Yes, the major problem here is using an oauth token to get the user realm
and using it later for authorization.
OAuth is for authorization, in that aspect IMO, we need to re-design this
handler.
However, to come across with present issue with less effort I have below
suggestion.
I think
All:
With regards $subject[1]
Here we have authentication flow and authorization flow. Token validation
service is used at authentication and username is set by the validator.
However, when "Use user store domain in local subject identifier" is not
enabled in Local & Outbound Authentication
12 matches
Mail list logo
