+1 for having a new logger and logs at INFO level.

On Tue, Aug 7, 2018 at 9:45 AM, Ruwan Abeykoon <[email protected]> wrote:

> Hi Rushmin,
> +1 for a new logger.
> It should be INFO level. as it is for informational purpose and not debug
> purpose. We can still enable/disable with Log4J config.
>
> Cheers,
> Ruwan
>
> On Tue, Aug 7, 2018 at 9:38 AM Rushmin Fernando <[email protected]> wrote:
>
>> Hi Dulanja,
>>
>> Please see the inline response.
>>
>> On Mon, Aug 6, 2018 at 10:40 PM Dulanja Liyanage <[email protected]>
>> wrote:
>>
>>> IINM the requirement here is to log the token generation event, not resource
>>> access with the generated token. Therefore access log won't be the
>>> correct place. This should be ideally logged in a separate log file, but we
>>> would have to use the audit log file because that's the existing option we
>>> have.
>>>
>>> However, not all customers will require this. This will in fact grow the
>>> audit log rapidly. So this should be configurable.
>>>
>>
>> To solve this we can use a different logger for these new logs and the
>> logs should be in debug level. So the new logs won't be visible in an
>> existing deployment. If a customer needs to see these logs, they just need
>> to configure log4j to enable DEBUG for the new logger and direct the logs
>> to a different file.
>>
>>
>>
>>>
>>> On Mon, Aug 6, 2018 at 3:30 PM, Ruwan Abeykoon <[email protected]> wrote:
>>>
>>>> HI Rushmin,
>>>> It is valid requirement to log the information.
>>>> Access log is the the right place for this kind of logs, as it logs
>>>> who/what accessed the Application with token.
>>>>
>>>> Audit log in contrast logs who did what modification at what resource.
>>>>
>>>> Cheers.
>>>> Ruwan
>>>>
>>>> On Mon, Aug 6, 2018 at 1:36 PM Rushmin Fernando <[email protected]>
>>>> wrote:
>>>>
>>>>> It is a valid requirement for a production deployment to publish/log
>>>>> context data during the operations like OAuth token generation.
>>>>>
>>>>> As of now, we don't log these audio data. One close existing candidate
>>>>> is HTTP access logs. But it doesn't contain any context information like
>>>>> client ID.
>>>>>
>>>>> What we can do is, use an audit logger in relevant classes and start
>>>>> logging the data.
>>>>>
>>>>> Do we have any concerns with this?
>>>>>
>>>>> --
>>>>> *Best Regards*
>>>>>
>>>>> *Rushmin Fernando*
>>>>> *Technical Lead*
>>>>>
>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>>>>
>>>>> mobile : +94775615183
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> *Ruwan Abeykoon*
>>>> *Associate Director/Architect**,*
>>>> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
>>>> *lean.enterprise.middleware.*
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Dulanja Liyanage
>>> Lead, Platform Security Team
>>> WSO2 Inc.
>>>
>>
>>
>> --
>> *Best Regards*
>>
>> *Rushmin Fernando*
>> *Technical Lead*
>>
>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>
>> mobile : +94775615183
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
>
> *Ruwan Abeykoon*
> *Associate Director/Architect**,*
> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
> *lean.enterprise.middleware.*
>
>


-- 
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to