Hi Prabath, Please find the comments inline. > > I assume this is a server level configuration. How do we handle > multitenancy in this scenario...? > After authentication is successful it returns an object which consist of username and tenantId of the authenticated client[1]. This object is then saved in memory along with the clientID to be used for authorization.
> > >> Similarly for Basic Authentication it will follow a role based >> authorization. In the implementation aspect in the MB this needs to done >> within the authenticator extension. >> > > It does not look good that we differenticate how to authorize users based > on how they authenticate into the system. Can't we make it generic.. I > don't think its the right approach to validate the scopes inside the > authenticator itself. Authorization should be decoupled... Let it be basic > auth or oauth - you need to have permission foo to connect to the broker.. > +1 I have already made the changes to decouple it, I will be updating it > soon. > >> >> *Level 2:* >> In MQTT specification it has been mentioned that: >> *"An implementation may restrict access to Server resources based on >> information provided by the Client such as User Name, Client Identifier, >> the hostname/IP address of the Client, or the outcome of authentication >> mechanisms."* >> >> In here we will be following the second approach where outcome of >> authentication will be passed to authorization. >> > > How do we do that.. how we keep the authentication session information > informationn between multiple requests... > When the authentication is successful during the connection then the message broker keeps track of the client information(MQTTAuthorizationSubject ) in memory along with its clientId[2]. so whenever a client publishes or subscribes to a topic then it will check if the clientId has the permission to publish/subscribe to the topic by passing the MQTTAuthorizationSubject object to the authoriser implementation.. > > >> >> In Level 2 the required steps to authrozie will be. >> >> *Publisher flow*, >> After the client gets connected then it will publish the message to a >> particular topic. >> In here we have the information related to the client which is stored and >> retrieved after authentication(this could be scopes that are related to the >> token or the username) and the topic that the client needs to publish. >> > > I assume the one who creates the topic can specify the level of > permissions required to publish to that topic... > > >> *Subscriber flow* >> In subscriber flow the client has the similar information as publisher >> that are retrieved from authentication. However in the subscribe use case >> it can subscribe to multiple topics. >> > > Here to I assume for each topic one who creates the topic can specify the > level of permissions required to subscribe to that topic... > > Yes it is, topic will be created when a subscriber subscribes or publisher publishes in the first time. however a permission needs to be mapped by the creator for that topic. >> For both instances if the authorization fails then the client will be >> disconnected from the broker. >> > > Is there a way to send back an error code in MQTT for authorization > failure..? > yes it is in mqtt spec 3.1.1 and since not all the mqtt client supports it and for now have sent the error code NOT_AUTHORIZED only for protocol 3.1.1 and have disconnected the client from the broker. Please correct me If I have missed anything. [1] https://github.com/ayyoob/andes/blob/oauth-permission/modules/andes-core/broker/src/main/java/org/dna/mqtt/moquette/server/AuthenticationInfo.java [2] https://github.com/ayyoob/andes/blob/oauth-permission/modules/andes-core/broker/src/main/java/org/wso2/andes/mqtt/MQTTAuthorizationSubject.java Thanks Ayyoob
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
