Hi Pamod,

The only issue with this approach as you have mentioned is propagating the
error to the client side. If a publisher does not have permission to
publish to a certain tenant and is trying to publish with QOS 1 or 2, will
this result in client retrying the publish? If so to avoid this we can send
a PUBACK although the publish is not complete, but that be an incorrect
PUBACK message.

So how should we handle the PUBACK sent from the broker and avoid the
client retries?


Thanks,
Akalanka

On Fri, Apr 17, 2015 at 11:33 AM, Pamod Sylvester <[email protected]> wrote:

> Hi Akalanka,
>
> One way i could think of as a solution would be to,
>
> 1) When the publisher/subscriber connection is established we need to
> maintain an additional attribute to identify the tenant information.
>
> i.e in NettyChannel (ServerChannel) class contains the server session
> information. Here we can introduce an additional attribute to identify
> tenant information that the connection is authorized.
>
> 2) Each time when a message is published or subscription occurs, the
> relevant ServerChannel is passed onto  the ProtocolProcessor. Here we could
> validate the published/subscribed topic against the attributes we added
> into the ServerChannel.
>
> The above is one approach. The only issue i could see here is to propagate
> the error message back to the client if the validation fails. Since the
> specification 3.1 does not allow that. In this case we could only log the
> error message in the server.
>
> WDYT ?
>
> Thanks,
> Pamod
>
>
>
> On Thu, Apr 16, 2015 at 4:54 PM, Akalanka Pagoda Arachchi <
> [email protected]> wrote:
>
>> Hi all,
>>
>> We have come across an impediment while trying to implement $subject.
>>
>> According to MQTT protocol specifications mentioned above, the username
>> and password is provided to broker by MQTT client only at the time of
>> connection. After creating the connection, the client can subscribe to any
>> topic and publish to any topic regardless of the tenant.
>>
>> Since the security information is not provided by MQTT client at
>> subscribe time and publish time how can we implement security on them? Is
>> it a good idea to keep the connection details of the client in memory and
>> do the validation using them at publish and subscribe time?
>>
>> Thanks,
>> Akalanka.
>>
>> On Thu, Apr 16, 2015 at 12:14 PM, Srinath Perera <[email protected]>
>> wrote:
>>
>>> +1
>>>
>>> On Fri, Apr 10, 2015 at 11:35 AM, Pamod Sylvester <[email protected]>
>>> wrote:
>>>
>>>> +1 to make it mandatory to provide username/password. Otherwise we
>>>> might leave out a vulnerable system in hands.
>>>>
>>>> On Fri, Apr 10, 2015 at 11:30 AM, Akalanka Pagoda Arachchi <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> We are planning to implement tenant support for MQTT in Message Broker
>>>>> 3.0.0. This requires a client to always provide a username and a password
>>>>> when connecting from a tenant.
>>>>>
>>>>> However, MQTT specification [1] states that security is non normative
>>>>> and therefore users can use the system with or without security. However,
>>>>> we're planning to make an exception in this case to make authentication
>>>>> mandatory for MQTT when connecting via a tenant.
>>>>>
>>>>> Thanks,
>>>>> Akalanka
>>>>>
>>>>>
>>>>>
>>>>> [1] -
>>>>> http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718111
>>>>>
>>>>> --
>>>>> *Darshana Akalanka Pagoda Arachchi,*
>>>>> *Software Engineer*
>>>>> *078-4721791 <078-4721791>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Pamod Sylvester *
>>>>  *Senior Software Engineer *
>>>> Integration Technologies Team, WSO2 Inc.; http://wso2.com
>>>> email: [email protected] cell: +94 77 7779495
>>>>
>>>
>>>
>>>
>>> --
>>> ============================
>>> Srinath Perera, Ph.D.
>>>    http://people.apache.org/~hemapani/
>>>    http://srinathsview.blogspot.com/
>>>
>>
>>
>>
>> --
>> *Darshana Akalanka Pagoda Arachchi,*
>> *Software Engineer*
>> *078-4721791 <078-4721791>*
>>
>
>
>
> --
> *Pamod Sylvester *
>  *Senior Software Engineer *
> Integration Technologies Team, WSO2 Inc.; http://wso2.com
> email: [email protected] cell: +94 77 7779495
>



-- 
*Darshana Akalanka Pagoda Arachchi,*
*Software Engineer*
*078-4721791*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to