Hi Hasintha,
> The interface (API) will consist of three main methods. > > 1) canAuthenticate - Decides whether the particular authenticator can > authenticate the incoming request or not. > > 2) authenticateClient - Authenticates the client request based on > information present. As a result of authentication client ID will be > available in the context. > > 3) getClientId - Depending on the authentication mechanism they way client > ID is extracted depends. For an example in JWT client authentication client > sends out the client Id within the JWT as the subject. Hence in a case > authenticaiton fails, we may need to extract client Id for other puposes. > ex - data publishing, if the client is non confidential. > What will be the method parameters for the above methods. I suppose we can and need to pass OAuthTOkenReqMessageContext for all the three methods as a parameter. So we can process the request and obtain the necessary query parameters from the request. Obtaining clientID may be different from mechanism to mechanism, but I think any how the request should contain the clientID. Thanks. Hasanthi On Mon, Jan 8, 2018 at 11:10 PM, Farasath Ahamed <[email protected]> wrote: > On Mon, Jan 8, 2018 at 4:49 PM, Hasintha Indrajee <[email protected]> > wrote: > >> The idea behind this is to decouple the authentication mechanism used by >> OAuth2 clients from the rest of the OAuth2 logic, so that different types >> of client authenticators can be plugged. For an example according to >> specification [1] client_secret_basic, client_secret_post, >> client_secret_jwt are few client authentication mechanisms. >> >> The client authentication will be done through an extension. Hence >> different client authentication criteria can be implemented and can be >> plugged. >> >> The interface (API) will consist of three main methods. >> >> 1) canAuthenticate - Decides whether the particular authenticator can >> authenticate the incoming request or not. >> >> 2) authenticateClient - Authenticates the client request based on >> information present. As a result of authentication client ID will be >> available in the context. >> >> 3) getClientId - Depending on the authentication mechanism they way >> client ID is extracted depends. For an example in JWT client authentication >> client sends out the client Id within the JWT as the subject. Hence in a >> case authenticaiton fails, we may need to extract client Id for other >> puposes. ex - data publishing, if the client is non confidential. >> >> The client authenticator has to be implemented as an OSGI bundle and >> should be deployed in dropins upon building. Also relevant authenticator >> name has to be configured in identity.xml under client authenticators. >> >> <ClientAuthHandlers> >> >> <ClientAuthHandler Class="org.wso2.carbon.identit >> y.oauth2.token.handlers.clientauth.BasicAuthClientAuthHandler"> >> </ClientAuthHandler> >> >> </ClientAuthHandlers> >> > > Do we have any plan in future to facilitate defining client authenticators > per OAuth application (service provider)? > Also do we have a way to define an oauth application as non-confidential > using the UI or do we need to write a custom client authentication handler > to do so? > >> >> [1] http://openid.net/specs/openid-connect-core-1_0.html#Cli >> entAuthentication >> <http://www.google.com/url?q=http%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23ClientAuthentication&sa=D&sntz=1&usg=AFQjCNEcVTdgiIUSObwbxp8OUtTU1By8Rg> >> >> >> >> >> >> >> -- >> Hasintha Indrajee >> WSO2, Inc. >> Mobile:+94 771892453 <077%20189%202453> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > -- Hasanthi Dissanayake Senior Software Engineer | WSO2 E: [email protected] M :0718407133| http://wso2.com <http://wso2.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
