Authentication across services in OpenLMIS spike

Hello!
We’ve been working on ticket OLMIS-668: Spike: Authentication across services, which deals with the research on how to do authentication across multiple services
and writing recommendation for OLMIS-546: Web Security. I’m attaching the results of our research. We will be grateful for your opinions. Please let us know if there is anything missing
that should be covered with this spike and if all points sound reasonable.

Best regards,
Weronika Ciecierska

OpenLMISSecurity.pdf (190 KB)

Thanks Weronika. Just a few quick questions so far:

  •      Doc states that two roles are defined, User and Admin.  By roles, are you referring to the Roles as found in OpenLMIS today?  We can define many different roles, each with their own set of rights.  So, are the User and Admin examples of those Roles, or something else?
    
  •      On a similar note, often applications will have to run background processes, utility tasks or other “headless” processes.  Do we need any special facility for these sorts of superuser tasks?
    
  •      Again, similar to OPenLMIS 2.0, we will define Roles and rights.  Should those domains be owned by the proposed auth service, or owned by the reference data/requisition service?  If so, I imagine the auth service would communicate with the reference data service to retrieve the rights granted to the user in question…?
    

Thanks - Rich

···

Hello!

We’ve been working on ticket OLMIS-668: Spike: Authentication across services, which deals with the research on how to do authentication across multiple services

and writing recommendation for OLMIS-546: Web Security. I’m attaching the results of our research. We will be grateful for your opinions. Please let us know if there is anything missing

that should be covered with this spike and if all points sound reasonable.

Best regards,

Weronika Ciecierska

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/1a8a1225-c107-4ad0-b373-ab7e77d2b3f5%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hi Rich, thank you for your questions.

  • User and Admin are two basic roles that we chose to define for now, because as in OpenLMIS today we do not know what kind of roles should be exactly defined. If they are specified somwhere in documentation, I will be grateful for link to the source and I will change the doc. Of course it will be possible to define multiple roles with different rigths, so User and Admin can be treated as an example for now.

  • If a proccess is not invoked by user, a service will not have a token to provide to the auth service to authenticate. I think that the best solution would be for service to generate its’ own token and sign it with shared key when making request to another service. Our defined in doc token contais payload with username which allows auth service to retrieve user’s roles. The question is how to retrieve service’s roles from the token.
    For now I can see two solutions:

  1. Token’s payload generated by service would be different than the one from user - with roles and service’s name defined.
  2. Token’s payload would contain roles/permissions in all cases (also for user’s tokens).
  • I think those domains should be owned by reference data service, because of the future UI - there surely will be some kind of users/roles management panel for admin. User’s role will be retrieved by auth service by making request using data from token.

Best regards,
Weronika

···

On Tuesday, 28 June 2016 22:23:15 UTC+2, Rich Magnuson wrote:

Thanks Weronika. Just a few quick questions so far:

  •      Doc states that two roles are defined, User and Admin.  By roles, are you referring to the Roles as found in OpenLMIS today?  We can define many different roles, each with their own set of rights.  So, are the User and Admin examples of those Roles, or something else?
    
  •      On a similar note, often applications will have to run background processes, utility tasks or other “headless” processes.  Do we need any special facility for these sorts of superuser tasks?
    
  •      Again, similar to OPenLMIS 2.0, we will define Roles and rights.  Should those domains be owned by the proposed auth service, or owned by the reference data/requisition service?  If so, I imagine the auth service would communicate with the reference data service to retrieve the rights granted to the user in question…?
    

Thanks - Rich

From: openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Weronika Ciecierska

Sent: Wednesday, June 22, 2016 8:39 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Subject: [openlmis-dev] Authentication across services in OpenLMIS spike

Hello!

We’ve been working on ticket OLMIS-668: Spike: Authentication across services, which deals with the research on how to do authentication across multiple services

and writing recommendation for OLMIS-546: Web Security. I’m attaching the results of our research. We will be grateful for your opinions. Please let us know if there is anything missing

that should be covered with this spike and if all points sound reasonable.

Best regards,

Weronika Ciecierska

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to
openl...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/1a8a1225-c107-4ad0-b373-ab7e77d2b3f5%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

This is looking great, thanks.

Josh

···

On Jun 29, 2016, at 4:14 AM, Weronika Ciecierska wciecierska@soldevelo.com wrote:

Hi Rich, thank you for your questions.

  • User and Admin are two basic roles that we chose to define for now, because as in OpenLMIS today we do not know what kind of roles should be exactly defined. If they are specified somwhere in documentation, I will be grateful for link to the source and I will change the doc. Of course it will be possible to define multiple roles with different rigths, so User and Admin can be treated as an example for now.

  • If a proccess is not invoked by user, a service will not have a token to provide to the auth service to authenticate. I think that the best solution would be for service to generate its’ own token and sign it with shared key when making request to another service. Our defined in doc token contais payload with username which allows auth service to retrieve user’s roles. The question is how to retrieve service’s roles from the token.

For now I can see two solutions:

  1. Token’s payload generated by service would be different than the one from user - with roles and service’s name defined.

  2. Token’s payload would contain roles/permissions in all cases (also for user’s tokens).

  • I think those domains should be owned by reference data service, because of the future UI - there surely will be some kind of users/roles management panel for admin. User’s role will be retrieved by auth service by making request using data from token.

Best regards,

Weronika

On Tuesday, 28 June 2016 22:23:15 UTC+2, Rich Magnuson wrote:

Thanks Weronika. Just a few quick questions so far:

  •      Doc states that two roles are defined, User and Admin.  By roles, are you referring to the Roles as found in OpenLMIS today?  We can define many different roles, each with their own set of rights.  So, are the User and Admin examples of those Roles, or something else?
    
  •      On a similar note, often applications will have to run background processes, utility tasks or other “headless” processes.  Do we need any special facility for these sorts of superuser tasks?
    
  •      Again, similar to OPenLMIS 2.0, we will define Roles and rights.  Should those domains be owned by the proposed auth service, or owned by the reference data/requisition service?  If so, I imagine the auth service would communicate with the reference data service to retrieve the rights granted to the user in question…?
    

Thanks - Rich

From:

openlm...@googlegroups.com [mailto:openlm...@googlegroups.com] On Behalf Of Weronika Ciecierska

Sent: Wednesday, June 22, 2016 8:39 AM

To: OpenLMIS Dev openlm...@googlegroups.com

Subject: [openlmis-dev] Authentication across services in OpenLMIS spike

Hello!

We’ve been working on ticket OLMIS-668: Spike: Authentication across services, which deals with the research on how to do authentication across multiple services

and writing recommendation for OLMIS-546: Web Security. I’m attaching the results of our research. We will be grateful for your opinions. Please let us know if there is anything missing

that should be covered with this spike and if all points sound reasonable.

Best regards,

Weronika Ciecierska

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev...@googlegroups.com.

To post to this group, send email to
openl...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/1a8a1225-c107-4ad0-b373-ab7e77d2b3f5%40googlegroups.com
.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/7726833a-75f1-4838-aeff-06010f73df24%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.