Hi All,
We have below 3 issues that are caused mainly because we don't have a clear
way to distinguish local and federated users in oauth related tables
(authorization code and access token storage).
There are few more issues related to sending subject claim in proper format
in IDtoken, that needs
In the current implementation of SAML and JWT bearer grants we treat the
user coming with the grants as federated users always.
This is not always the case since there are scenarios where the SAML/JWT
token will be issued by the same IS instance that will accept them later as
bearer grants and is
How is this going to impact migrating clients? For the data that's already
available in the DB, I guess we won't be changing their user store domains.
So I guess they will still be treated in the old way?
On Tue, May 16, 2017 at 7:53 PM, Pushpalanka Jayawardhana
wrote:
> Hi All,
>
> We have belo
How do you figure out users from different idps?
Thanks & regards,
-Prabath
On Tue, May 16, 2017 at 7:23 AM, Pushpalanka Jayawardhana
wrote:
> Hi All,
>
> We have below 3 issues that are caused mainly because we don't have a
> clear way to distinguish local and federated users in oauth related
On Tue, May 16, 2017 at 10:25 PM, Prabath Siriwardena
wrote:
> How do you figure out users from different idps?
>
In this way we can only identify whether use is federated or local user.
But we can use a convention to keep IDP name as well if we need to go
without schema changes
Ex FEDERATED:IDP
On Tue, May 16, 2017 at 10:19 PM, Nuwan Dias wrote:
> How is this going to impact migrating clients? For the data that's already
> available in the DB, I guess we won't be changing their user store domains.
> So I guess they will still be treated in the old way?
>
Yes, as of now we save domain as
On Tue, May 16, 2017 at 11:15 PM, Ishara Karunarathna
wrote:
>
>
> On Tue, May 16, 2017 at 10:25 PM, Prabath Siriwardena
> wrote:
>
>> How do you figure out users from different idps?
>>
> In this way we can only identify whether use is federated or local user.
>
> But we can use a convention to
Also - related to JWT/SAML grant types - do we have an option to JIT
provision the user...? The expectation is - when you enable JIT
provisioning under the trusted IdP - and pick the userstore to provision
the users - then the user should be JIT provisioned...
Thanks & regards,
-Prabath
On Tue, M
On Wed, May 17, 2017 at 10:26 AM, Prabath Siriwardena
wrote:
> Also - related to JWT/SAML grant types - do we have an option to JIT
> provision the user...?
>
This is not available in the current implementation.
> The expectation is - when you enable JIT provisioning under the trusted
> IdP - an
On Tue, May 16, 2017 at 10:04 PM, Ishara Karunarathna
wrote:
>
>
> On Wed, May 17, 2017 at 10:26 AM, Prabath Siriwardena
> wrote:
>
>> Also - related to JWT/SAML grant types - do we have an option to JIT
>> provision the user...?
>>
> This is not available in the current implementation.
>
>> The
On Wed, May 17, 2017 at 10:37 AM, Prabath Siriwardena
wrote:
>
>
> On Tue, May 16, 2017 at 10:04 PM, Ishara Karunarathna
> wrote:
>
>>
>>
>> On Wed, May 17, 2017 at 10:26 AM, Prabath Siriwardena
>> wrote:
>>
>>> Also - related to JWT/SAML grant types - do we have an option to JIT
>>> provision
On Wed, May 17, 2017 at 10:37 AM, Prabath Siriwardena
wrote:
>
>
> On Tue, May 16, 2017 at 10:04 PM, Ishara Karunarathna
> wrote:
>
>>
>>
>> On Wed, May 17, 2017 at 10:26 AM, Prabath Siriwardena
>> wrote:
>>
>>> Also - related to JWT/SAML grant types - do we have an option to JIT
>>> provision
Can we give the option to provision the user...? This requires no UI
changes - can read the option from the IdP config...
Thanks & regards,
-Prabath
On Tue, May 16, 2017 at 10:26 PM, Ishara Karunarathna
wrote:
>
>
> On Wed, May 17, 2017 at 10:37 AM, Prabath Siriwardena
> wrote:
>
>>
>>
>> On T
Yes - we know the issuer of the token - so we can control what to
provision
Thanks & regards,
-Prabath
On Wed, May 17, 2017 at 9:11 AM, Farasath Ahamed wrote:
> In the current implementation of SAML and JWT bearer grants we treat the
> user coming with the grants as federated users always.
On Wed, May 17, 2017 at 10:17 PM, Prabath Siriwardena
wrote:
> Yes - we know the issuer of the token - so we can control what to
> provision
>
If we provision the user how do we treat him in the oauth tables as a
federated user of local user ?
I think we have to treat it as a local user and s
15 matches
Mail list logo
