[IS] Audit logs for token generation.

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[IS] Audit logs for token generation.

Rushmin Fernando
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. - Lean . Enterprise . Middleware 

mobile : +94775615183



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IS] Audit logs for token generation.

Ruwan Abeykoon
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 <[hidden email]> 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. - Lean . Enterprise . Middleware 

mobile : +94775615183




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IS] Audit logs for token generation.

Dulanja Liyanage
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. 

On Mon, Aug 6, 2018 at 3:30 PM, Ruwan Abeykoon <[hidden email]> 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 <[hidden email]> 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. - Lean . Enterprise . Middleware 

mobile : +94775615183




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IS] Audit logs for token generation.

Rushmin Fernando
Hi Dulanja,

Please see the inline response.

On Mon, Aug 6, 2018 at 10:40 PM Dulanja Liyanage <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. - Lean . Enterprise . Middleware 

mobile : +94775615183




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
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. - Lean . Enterprise . Middleware 

mobile : +94775615183



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IS] Audit logs for token generation.

Ruwan Abeykoon
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 <[hidden email]> wrote:
Hi Dulanja,

Please see the inline response.

On Mon, Aug 6, 2018 at 10:40 PM Dulanja Liyanage <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. - Lean . Enterprise . Middleware 

mobile : +94775615183




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
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. - Lean . Enterprise . Middleware 

mobile : +94775615183


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IS] Audit logs for token generation.

Ishara Cooray
+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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Dulanja,

Please see the inline response.

On Mon, Aug 6, 2018 at 10:40 PM Dulanja Liyanage <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. - Lean . Enterprise . Middleware 

mobile : +94775615183




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
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. - Lean . Enterprise . Middleware 

mobile : +94775615183


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IS] Audit logs for token generation.

Chamila De Alwis
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Hi Dulanja,

Please see the inline response.

On Mon, Aug 6, 2018 at 10:40 PM Dulanja Liyanage <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. - Lean . Enterprise . Middleware 

mobile : +94775615183




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
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. - Lean . Enterprise . Middleware 

mobile : +94775615183


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [IS] Audit logs for token generation.

Dulanja Liyanage
In reply to this post by Ruwan Abeykoon
+1 for having a new logger and logs at INFO level. 

On Tue, Aug 7, 2018 at 9:45 AM, Ruwan Abeykoon <[hidden email]> 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 <[hidden email]> wrote:
Hi Dulanja,

Please see the inline response.

On Mon, Aug 6, 2018 at 10:40 PM Dulanja Liyanage <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. - Lean . Enterprise . Middleware 

mobile : +94775615183




--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.


_______________________________________________
Architecture mailing list
[hidden email]
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. - Lean . Enterprise . Middleware 

mobile : +94775615183


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


--
Ruwan Abeykoon
Associate Director/Architect,
WSO2, Inc. http://wso2.com 
lean.enterprise.middleware.




--
Thanks & Regards,
Dulanja Liyanage
Lead, Platform Security Team
WSO2 Inc.


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture