Access logs have a specific format and a set of information that can be
easily interpreted by existing log collection and analysis tools. Adding
new and custom formats to this will make it harder to aggregate and analyze
access logs properly. So this should be a separate log.

Furthermore, it might be better to provide functionality (maybe at log4j
level) to have per SP log files if needed. That would ease post-fact
analysis a lot, especially in deployments with heavy activity.

What kind of performance recommendations would we have with this? Would
this affect the token generation performance numbers?

Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Associate Technical Lead | WSO2
+94 77 220 7163
Blog: https://medium.com/@chamilad




On Tue, Aug 7, 2018 at 10:27 AM Ishara Cooray <[email protected]> wrote:

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

Reply via email to