> > On Mon, Feb 8, 2016 at 11:06 PM, Ayyoob Hamza <ayy...@wso2.com> 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..? > In here for the for OAUTH token authenticator implementation, I have used the super tenant user to call the admin service and this supports to validate the token for the user from other tenants. Therefore have maintained only one configuration file for the implementation of OAuth Authenticator.
>>> >>>> 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 mqtt the connection and publish/subscribe are two separate steps. Client id can be any unique id used to create the mqtt connection. Once the connection is made (Step 1) to the broker it authenticates the connected client and stores the unique "clientId" in the session. Furthermore two clients with same clientId cannot connect to the broker at the same time, it allows only one to be connected. In a subsequent call for subscription/publish, the broker authorizers the client against the clientId created for the connection. And this clientId is retreived from the session related to the connection in Step 1. In IoT server example we have used concat string of deviceType and deviceId(Assuming that the deviceId is unique to a device type). Thanks > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
