On Wed, Oct 26, 2016 at 4:42 PM, Darshana Gunawardana <[email protected]>
wrote:
> For federated users, it's ok to prompt missing attributes every time
> (unless they are associated and assert with a local user). I think we
> should display a message like [1].
>
> What happens when we try federated login that associated with local user
> and also assert with local user? Does that work without changing current
> implementation?
>
- yes. In this case it will retrieve saved claims from local
account.
>
> And giving the option to associate user during the JIT provioning is an
> addional capability which also requested by many. We would need to done as
> a improvement for JIT provioning. For the perspective of this feature, if
> it works with manually associated (and locally asserted users), it would
> also work automatically associated users.
>
> [1] "You are trying login to application x, but it need following
> information filled in the user profile. You can fill those below and
> proceed with the authentication. But it's adviced to fill this information
> in your y-IdP profile in order to avoid this step every time you login."
>
> Thanks,
>
>
> On Wednesday, 26 October 2016, Nuwandi Wickramasinghe <[email protected]>
> wrote:
>
>> Hi,
>>
>> This feature includes saving the attributes provided at authentication
>> time to the user profile so the mandatory attributes will be present in the
>> user profile from the next time user tries to access the application. At
>> the moment, attributes are saved only for the local users.
>>
>> If the user is coming from a federated identity provider and the
>> federated idp does not send any of the mandatory attributes, user will be
>> prompted to provide them during the authentication. These provided
>> attributes will be sent to the application but not saved. Therefore if the
>> user tries to access the application again, he might have to provide the
>> same attributes (if idp is not sending them).
>>
>> If JIT provisioning is enabled for this identity provider, this federated
>> user will be provisioned to a local user store where we can update and save
>> provided attributes. But when this federated user tries to access the
>> application again, unless the federated user has an association with a
>> local account, handlePostAuthentication() method does not read
>> attributes from a local account, resulting in user having to provide
>> attributes again.
>>
>> So if we need to avoid prompting for same attributes from the same user
>> (provisioned user) again and again we can do following,
>>
>> 1. For the JIT provisioned users, check the local profile for missing
>> attributes before requesting them from user.
>> 2. Automatically associate federated user with the provisioned user at
>> the time of provisioning.
>>
>> Any comments about the current issue and above two suggestions and/or new
>> suggestions are highly appreciated.
>>
>> thanks and best regards
>> Nuwandi
>>
>> On Wed, Oct 26, 2016 at 3:21 PM, Nuwandi Wickramasinghe <
>> [email protected]> wrote:
>>
>>> Hi all,
>>>
>>> This new feature, provided with IS 5.3.0, allows to define mandatory
>>> attributes for an application during the Service Provider configuration
>>> time. When a user tries to access the application, during authentication,
>>> IS will check whether the user has mandatory attributes requested by the
>>> application. If any mandatory attribute is missing, IS will prompt a page
>>> where user can provide mandatory claims for that application.
>>>
>>> Current implementation is to check the missing mandatory claims at the
>>> authentication framework as a post authentication task.
>>> *DefaultStepBasedSequenceHandler* handles the authentication from the
>>> steps configured for the application. Once all the steps are successfully
>>> completed, *handlePostAuthentication() *method is fired. This method
>>> gets the user attributes from attribute step and adds them to
>>> *AuthenticatedUser* object which will be used to send user details to
>>> the application. Handling of missing mandatory attributes, is implemented
>>> as a post authentication extension. Post authentication extension is called
>>> at the end of *handlePostAuthentication().*
>>>
>>> After post authentication is done, following additional steps are
>>> implemented for the feature.
>>>
>>> 1. Post authentication extension compares mandatory attributes defined
>>> in Service Provider configuration with the user attributes found in
>>> AuthenticatedUser object. ( If no attributes are missing, it proceeds with
>>> Authentication Complete state)
>>>
>>> (If one or more attributes are missing)
>>> 2. Authentication and sequence is set to "Incomplete" state. A property
>>> is set in Authentication Context to identify that post authentication
>>> extension triggered an action.
>>>
>>> 3. User is redirected to a page which requests missing attributes.
>>>
>>> 4. Once user submits values in the page, a post request is made to the
>>> authentication framework (commonauth servlet) with attribute values and
>>> context identifier (sent from the framework).
>>>
>>> 5. Authentication framework identifies the authenticated context from
>>> the context identifier. Framework will skip authentication steps since it's
>>> already authenticated and set the sequence state to "completed" and then
>>> call *handlePostAuthentication().*
>>>
>>> 6. In *handlePostAuthentication()*, it checks the property set in step
>>> 2 and identifies this as the response of post authentication extension task
>>> therefore calls the post authentication extension.
>>>
>>> 7. Response handler in post authentication extension, reads the
>>> attributes from request, sets them as user attributes in AuthenticatedUser
>>> object and completes the authentication. So application will receive all
>>> the mandatory attributes for that.
>>>
>>> this is the current implementation of this feature.
>>>
>>> thank you
>>> Nuwandi
>>>
>>> --
>>>
>>> Best Regards,
>>>
>>> Nuwandi Wickramasinghe
>>>
>>> Software Engineer
>>>
>>> WSO2 Inc.
>>>
>>> Web : http://wso2.com
>>>
>>> Mobile : 0719214873
>>>
>>
>>
>>
>> --
>>
>> Best Regards,
>>
>> Nuwandi Wickramasinghe
>>
>> Software Engineer
>>
>> WSO2 Inc.
>>
>> Web : http://wso2.com
>>
>> Mobile : 0719214873
>>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Associate Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: [email protected] <[email protected]>*
> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>
>
--
Best Regards,
Nuwandi Wickramasinghe
Software Engineer
WSO2 Inc.
Web : http://wso2.com
Mobile : 0719214873
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
