+1 to have a new File Logging appender for the new audit logs as it makes
easier to analyze the logs as well.
But we may need to set additivity property to false in order to avoid
appending these logs to main logger.


Thanks & Regards,
Ishara Cooray
Senior Software Engineer
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

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

Reply via email to