Hi All, Thanks for the inputs.
@Dulanja: In my case the apps may either be OIDC or SAML. We can't do Idp initiated login for OIDC. Am I correct? And in between we have to clean the cookies also which again seems to be challenging. @Farasath, Thanuja : Sending user back to application and re initiating with force auth requires the app to be modified. Unfortunately, It's impossible for me to modify the apps since I don't have the control over them. Meanwhile I tried few other options and the following option seems to be working. At the last authenticator (which will never be skipped), provided a separate link with context id and a reset parameter. At authenticator process response method, If I get the reset parameter set I clear up all the cookies, set a reset flag in context, and throw an authentication failed exception. Authentication framework will then retry the authenticator (I have retry enabled for this authenticator) and call initiate method of the same authenticator. At initiate method I check whether the reset flag is set. If it set, I retrieve the authentication request object from the context which will have initial authentication request parameters. Build the initial URL from those parameters available and redirect user to that original request URL (instead of redirecting users to the authenticator page as we usually do). This will replay the initial request from app to IS. And IS will see this as a new session as we have already cleared the cookies. So the user will have to complete all the steps. Then I thought of the SAML post binding scenario also where I can't do a redirect to replay initial request. For that I checked whether the initial request was a POST request and built a response which contains an auto submitting HTML form with the initial request parameters, where it would replay the initial POST request. I had the initial tests covering OIDC (authz code), SAML (post and redirect binding) and seems to be working fine. There are still couple of minor issues this approach also. One is the exception message we throw will get printed to log as an authentication error, and this will trigger an authentication failure event which is not really the case. Please let me know if you see any other major issues with the above approach or if there is any better approach. On Thu, Mar 2, 2017 at 10:52 PM, Farasath Ahamed <farasa...@wso2.com> wrote: > > > On Thu, Mar 2, 2017 at 10:34 AM, Thanuja Jayasinghe <than...@wso2.com> > wrote: > >> Hi Pulasthi, >> >> The best approach is to ask Alice to log-out when she leaves the browser. >> >> Or from the application side, we can give an option like "fresh-login" >> which sends a "forceAuth=true" request to the IS. So he will go through the >> authentication process again. >> >> > Yes. I have seen this in gmail where the last logged in accounts are > remembered and are listed when we try to login. There is another option > saying "Add new account" which allows a new user to login. > > Can't we follow a similar approach? > > Thanks, >> Thanuja >> >> >> On Thu, Mar 2, 2017 at 3:14 AM, Pulasthi Mahawithana <pulast...@wso2.com> >> wrote: >> >>> In IS 5.3.0, I have configured the authentication flow for an >>> application to have 3 steps. During the authentication flow, the users may >>> remember the result of the first two steps (using cookies) in their initial >>> login. So, in subsequent logins they'll see the third step straight away in >>> which they always need to get authenticated. >>> >>> Let's say 'Alice' logs in and remember the result for the first two >>> steps and finish her work. After some time 'Bob' also use the same browser >>> and try to login. He won't see the first two steps because there is an >>> already remembered result from Alice's login. But in the third step he >>> can't authenticate because he doesn't know Alice's credentials (and he >>> intend to login as 'Bob'). So he needs to start over the flow as 'Bob'. >>> When he does so, at IS, we should clear the remembered results for 'Alice' >>> and allow the the user to try with a different username (This time he >>> should get authenticated from all 3 steps). How can we achieve this >>> requirement? Is there a known approach? >>> >>> >>> -- >>> *Pulasthi Mahawithana* >>> Senior Software Engineer >>> WSO2 Inc., http://wso2.com/ >>> Mobile: +94-71-5179022 <+94%2071%20517%209022> >>> Blog: https://medium.com/@pulasthi7/ >>> >>> <https://wso2.com/signature> >>> >>> _______________________________________________ >>> Dev mailing list >>> Dev@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *Thanuja Lakmal* >> Senior Software Engineer >> WSO2 Inc. http://wso2.com/ >> *lean.enterprise.middleware* >> Mobile: +94715979891 +94758009992 >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > -- *Pulasthi Mahawithana* Senior Software Engineer WSO2 Inc., http://wso2.com/ Mobile: +94-71-5179022 Blog: https://medium.com/@pulasthi7/ <https://wso2.com/signature>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
