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.*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to