Hi Devs, This is with respect to [1] reported.
This issue has been occurred due to the fix done over [2] as per the architectural discussion at [3]. Previously when an authentication request comes for an active session, in each step we validated if the user has been authenticated over the respective IdP of a particular authenticator. The login prompted only if the user had not been authenticated with the respective IdP. Because of this validation below use case failed. - There are two SPs as A and B. - A had been configured for basic authentication - B had basic authenticator in the first step and FIDO in second step - User logged in to A providing username and password. User then access B. Even though the expectation is to prompt for authentication with FIDO device the user will get directly logged in. - This is because in both authenticators the IdP is picked as 'LOCAL'. So it just validated if the user had been authenticated over the respective IdP only. With [2] we had fixed this to validate both the IdP and the authenticator being authenticated with previously. Therefore, now, when request path basic authentication is configured for one of the apps and the other authenticates with the basic authenticator, even though the IdP is same, as the authenticators (validated against authenticator names) are different, login will be prompted. IMO, fix done over [2] is correct. Because, as I see, authenticator is the one which knows how to authenticate the user and the mechanism being used to authenticate the user. User being authenticated over a one mechanism for a IdP should not indicate that the user is authenticated by any other mechanism for the same IdP. But, when it comes to request path basic authentication and basic authentication the authentication mechanism is same. The only difference is the way the input is received for the authenticator. Therefore, as I see, it's the basic authenticator which should handle credentials coming in request. We can keep the request path authenticator as it is and improve the basic authenticator to cater this case. Anyhow, SSO for basic authentication had been broken for request path basic auth and default basic auth scheme at the moment with [2]. So, improving the basic authenticator will provide that capability back. WDYT? [1] https://github.com/wso2/product-is/issues/2192 [2] https://wso2.org/jira/browse/IDENTITY-6198 [3] https://mail.wso2.org/mailarchive/architecture/2017-July/028336.html Thanks, Malithi -- *Malithi Edirisinghe* Associate Technical Lead WSO2 Inc. Mobile : +94 (0) 718176807 [email protected]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
