On Mon, Feb 8, 2016 at 11:06 PM, Ayyoob Hamza <[email protected]> wrote:
> 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. > How do you maintain this configuration tenant-wise..? > >> >>> 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.. > How does the client send the clientid in subsequent requests...? > >> >>> >>> 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 > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
