Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

Hi, Following is the high level diagram of proposed design, ​ Claim handling should also be moved to Post Authentication handler, after JIT provisioning handler as we get new claims from the user in JIT. Following diagram shows the internal process logic of JIT handler ​Currently we do not

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

Thanks for explanations, the scenarios on when this is needed is now clear. On Wed, Apr 11, 2018 at 12:30 PM, Johann Nallathamby wrote: > Hi Nuwan, > > On Wed, Apr 11, 2018 at 5:43 PM, Nuwan Dias wrote: > >> Provisioning users with a known/proper password

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

Hi Nuwan, On Wed, Apr 11, 2018 at 5:43 PM, Nuwan Dias wrote: > Provisioning users with a known/proper password would make it possible for > them to login/authenticate directly against IS without being authenticated > against the federated IDP right? > Yes. The requirement is

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

Provisioning users with a known/proper password would make it possible for them to login/authenticate directly against IS without being authenticated against the federated IDP right? Do we really want to allow that? If internal admins want to manage their accounts internally, or if we want users

Re: [Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

Adding Dimuthu On Wed, Apr 11, 2018 at 3:21 PM, Menaka Jayawardena wrote: > Hi, > > In WSO2 Identity Server, users can be provisioned to the internal User > store when the users are signing up with social accounts. But in this case, > the users should always use the social

[Architecture] [IAM] Provisioning Users with Passwords when JIT Provisioning

Hi, In WSO2 Identity Server, users can be provisioned to the internal User store when the users are signing up with social accounts. But in this case, the users should always use the social login option to login to the application and the identity admins could not manage them as internal users.