Cloud-native microservices security

[Charlotte-Holt]

From LC: This is a new concept topic for an introduction to securing microservices- authentication and authorization in securing cloud-native microservices. Jakarta EE Security provides the capability to configure the basic authentication, form authentication, or custom form authentication mechanism by using annotations in servlets.

Include basic concepts of authentication and authorization and provide a diagram and description of authorization/authentication (see the following list of KC topics for more information, but don't just transfer the long concept topics from the KC) in a microservices scenario (for example, a developer wants to view account page on a website and get prompted to log in).

• https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_auth_filter.html
• https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_sec_sociallogin.html
• https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/cwlp_authentication.html
• https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/cwlp_authorization.html

Background information: https://www.ibm.com/cloud/garage/architectures/microservices/microservices-kubernetes-microprofile

Apps running on OL can be configured to use external security providers to handle authentication/authorization. This ensures that the app never directly accesses or stores the user's password. Using external security providers also relieves developers and administrators of the app of the effort of managing user accounts. Include information about Jakarta EE Security as it's relevant to these scenarios.

[ManasiGandhi]

Draft link for the issue https://draft-openlibertyio.mybluemix.net/docs/ref/general/#securing%20cloud%20native%20microservices.html

[dmuelle]

Peer review of draft at https://draft-openlibertyio.mybluemix.net/docs/ref/general/#securing%20cloud%20native%20microservices.html

• opening pp- combine 2nd two sentences after shortdesc into a single pp
• I think the Authentication overview could be at a higher level- leave the specifics for the Authentication topic. Just introduce the concept of Authentication here- the server gets credentials from the user and checks them against the data in a user registry to confirm a user's identity and permissions, and returns this information to the application. Link this section to the Authentication topic via the word "authentication" in the 1st sentence- https://draft-openlibertyio.mybluemix.net/docs/ref/general/#authentication.html
• For authorization- same thing- higher level- see my topic at https://draft-openlibertyio.mybluemix.net/docs/ref/general/#authorization.html. link to this topic in the first sentence of your section.

here's a KC topic that might be helpful- https://www.ibm.com/support/knowledgecenter/SSD28V_liberty/com.ibm.websphere.wlp.core.doc/ae/rwlp_sec_quick_overview.html?pos=2

• Jakarta EE- External security providers also save the application developers and administrators of the effort of managing user accounts. there's an extra "of" before "the effort"

Link each of the features you list to their entry in the gen doc

[Rwalls1]

@ManasiGandhi Peer review: Adding to the comments that you've already addressed in the PR here: https://github.com/OpenLiberty/docs/pull/982

• In the authentication section, add a noun such as application after access to the phrase "a request to access is verified", to prevent any confusion about what the request is referring to.
• Make sure to run acrolinx again as I noticed that it caught a few things that could be cleaned up.

[chirp1]

Notes: We've concluded that the topic should be a broader topic than what was originally dscribed at the beginning of this topic. David, Mansi, and I came up with the following list of security ideas for the topic. Manasi can use them as a starting point to discuss the contents of the topic with Ajay and Alasdair.

• Defence in Depth- Multiple layers of security
• Differences in security going from a monolithic to a microservice architecture. .
• Using an API gateway as a single entry point for all requests.
• Monitoring and tracing for security.

The topic, including additions/subtractions to the list should explain the importance of these areas of security and then the basics of how to implement them in an Open Liberty enviroment, with links to the more detailed topics.

[ManasiGandhi]

Initial draft link, https://draft-openlibertyio.mybluemix.net/docs/ref/general/#securing-microservices.html

[lauracowen]

Some small comments below but I think there needs to be a lot more info in this topic. However, I don't know what just yet. I think it might be better to come back to this when we have a full set of security docs together we can review so I'm going to spend time reviewing the other topics then I'll come back to this, if that's okay. Just put this on hold for a little while while we pull the other security topics together.

• "As applications move from monolithic to microservices architecture," I think remove that part of the first sentence. It's not only then that security is important. The rest of the sentence gets the point across by itself.
• go for simpler words when you can; eg "take precedence" could be "considered from the start of the development cycle". It's just easier to read if the language is simpler (as long as the relevant technical terms are used in the right places too).
• I don't think we need to talk about moving from monolithic to microservices - Open Liberty's docs are not there to support modernisation scenarios; they're there to support writing apps for the cloud.
• Another point that's become clearer more recently, is the recognition that microservices are not nirvana and sometimes monoliths are appropriate, depends on the app. So I think for now avoid assuming people are moving from one to the other (certainly in Open Liberty context).
• I'm not sure what the 'monitoring' section is saying that's relevant to security.

[ManasiGandhi]

@lauracowen Here's a link to the draft https://draft-openlibertyio.mybluemix.net/docs/ref/general/#securing-cloud-native-microservices.html . It is an initial draft with an outline that I need to check for accuracy.

[lauracowen]

Thanks. I think we have largely the right tech areas covered here but I think it needs to be shorter and more focused. I know we didn't have the purpose of this topic very clear so it's good to have this draft to start from. I'll try to describe what the aims are below and then suggest an outline to refocus/restructure the information.

Audience The audience of this topic is, specifically, application developers. As a developer, when you're writing an application, it's really easy to disregard security until you really have to do it, and then only what you really have to do. The importance of security is generally seen by the operations people (or more senior people in the org), not developers, because it's the operations people who have to keep the app up and running and not have bad people break into the organisation. Unless the developer is also doing the production-time ops for their app, while they may care, they probably don't know a lot about security, and it's not their greatest priority to learn or spend time on (there are other things that they need to spend time on).

Aim/purpose of this topic This topic needs to help the developer know what they must do to secure their app without them having to take loads of time learning everything there is to know about security. The aim is not to be an overview of all the security topics we have. I don't know if you've seen the draft of the navigation for the OL docs? https://antora.mybluemix.net/docs/latest/overview.html You'll see there's a Development section and a Security section. Most of the security information is in the Security section. However, this topic will be moved to the Development section when it's written. This will probably be the only security-related topic in the Development section, though it will have links to the other security topics for if the developer wants to know more. However, this topic needs to be sufficient for most developers to know what they need to do in order to secure their app, even if they need to look elsewhere for the specific details of some parts of that process. Think about presenting it so that it's useful and practical, rather than a wall of text, so that it leads the developer easily through the considerations they need to make but without overwhelming them with information. Avoid duplicating info that's elsewhere. Just keep it brief here.

Outline

• Start with why it's important to secure web services; eg prevent baddies intercepting data as it's transmitted between services or from services to the application user's client (web browser); helps stop them pretending to be someone else in order to access data they shouldn't be able to see; etc (find out a list of these kinds of things). Don't be patronising but we need to clearly illustrate what can happen if you don't secure your services.
• Then create a simple diagram identifying where the weaknesses are in a microservice architecture (don't have to use the bank app scenario below - it might not be the best example to use, but work with Charlotte and/or David to adapt the diagram that's in the Authentication topic):
  • verifying who a person is (ie authentication) - checking that they are who they say they are when they first access the app (eg logging into their online banking mobile app)
  • verifying that that person has permission to access the information that they're requesting (ie authorization)
  • eg checking that the app user has permission to see the information (eg a list of the accounts the end user has with that bank) presented to them on any of the pages of the app that they tap.
  • eg checking that when the app user tries to visit a webpage (eg view their account statement), they're allowed to see the info on that page - that information is held in a service that is separate to the mobile app itself (it's not all in the mobile app but held on one or more servers elsewhere) so the app has to request that information on the user's behalf - the app therefore needs to be able to prove that it has permission to do that (which is where tokens like JWT come in - the app gets a JWT from the authentication provider which it then passes with its request for information to prove it has permission to request that info).
• After the diagram, briefly describe the main weak points.
• Then address how to strengthen these weak points:
  • logging in (authentication) - need to be able to check the user's identity against a user registry that contains a list of users who are known to be able to log into this application.
  • For development purposes, the easiest thing is to create a basic registry (a text-based user registry directly in the app's server.xml file), or (if you just need a single user for a start) a quickstart registry (same but simpler). Neither of these is suitable for production use but very useful if you just need to be able to control different users' access to parts of your app.
    • Encrypt the password so it's not stored in plain text in your app: Link: securityUtility command.
    • Link: User registries topic (ideally to the basic registries section - talk to David about adding anchors to the sections in that topic?).
    • Link: "Securing a web application" guide
  • For production use
    • ideally use SSO because it means the user can use the app without having to create and use yet another account and login details.
    • it might depend on what the app is (eg what kind of access restrictions you might need to be able to control) and whether the developer's company already has a user registry that they want you to use. Eg if the company uses an LDAP registry (like IBM has Bluepages, which is an LDAP registry) you could set that up with SAML (like IBM does for your intranet/w3 ID); if the company uses Windows Active Directory for its employees to log into their laptops, might be best to use that with SPNEGO.
    • Assuming there aren't requirements to use an existing user registry, could just use a social media provider (Social Media Login feature enables this) so the social media platform manages to user registry and login procedure for you.
    • Link: Social media login guide (not quite published yet but will be soon).
  • permitting users to access certain info and not other info in the app (authorization) - need to define who is permitted to access certain pages in your web app.
  • Link: Securing a web app guide
  • permitting services within the application to access info on the user's behalf from other services. This is where JWT comes in.
  • App needs to generate a JWT which the service can send with its request to another service to show it has permission to request that info.
  • Link: JWT guide. Also https://openliberty.io/blog/2019/08/29/securing-microservices-social-login-jwt.html but maybe not the best place to link to? Not sure - see what you think.
• Encrypt traffic between services with TLS so that no one can intercept data or tokens being transmitted between services or between the client and a service.
• Finally, before production, make sure you work through the advice for hardening your app in Link: Security hardening for production topics.

[lauracowen]

Can you delete the additional "Securing cloud-native microservices" topic from the draft website? I think it's the old version but it has a different file name so it's there as well.

[lauracowen]

This is a reasonable start. I like the structure of separating out development from production. But the text itself very sparse and really just a list of links in paragraph form once you get to the production section. Don't focus on providing links to every topic (that's not the purpose of this topic); focus instead on providing useful information (whatever links that requires will be obvious as a consequence of doing that).

I know I said to keep it brief but it needs to be more helpful and to speak to the developer as if we understand their situation. Be wordy and helpful for now - don't worry about being brief - I wrote the outline above for a reason - you don't need to just extract the bare, dry facts from it - explain things in a way the developer can relate to. We can edit it down later if it gets a bit long. Explain things like you would if you were talking to someone in person.

• There need to be examples and it really needs some illustration to visually show what's needed (as I described above). The banking example I gave may not be the best idea but we need something (and we have other examples elsewhere if banking is not the best approach).

• "When users try to access your application you need to verify if the users are what they claim to be." -> "... who they claim to be." - you can't tell what they are, just who they are.

• There are a couple of dodgy links displaying in this topic. Can you check the topic over after it's built before putting it to review to make sure you catch build problems before the reviewers see it?

• Not sure why the "hardening" link targets the TLS topic? Was that meant to target one of Charlotte's hardening topics instead?

[ManasiGandhi]

@lauracowen I worked on your comments. I've pasted an initial diagram for your reference.

• [x] There need to be examples and it really needs some illustration to visually show what's needed (as I described above). The banking example I gave may not be the best idea but we need something (and we have other examples elsewhere if banking is not the best approach).

• [x] "When users try to access your application you need to verify if the users are what they claim to be." -> "... who they claim to be." - you can't tell what they are, just who they are.

• [x] There are a couple of dodgy links displaying in this topic. Can you check the topic over after it's built before putting it to review to make sure you catch build problems before the reviewers see it?

• [ ] Not sure why the "hardening" link targets the TLS topic? Was that meant to target one of Charlotte's hardening topics instead?

[lauracowen]

• Can you move this topic into the Development section of the navigation instead of the Security section? This is the only security-related topic that will be in the Development section (all the other security-related topics are for more of an ops audience).
• First paragraph, I think "to prevent unauthorized access to your application" is the reason for the first sentence in that paragraph, not the reason for the second sentence. The reason why you should secure your app earlier rather than later is (and I can't think how to phrase this properly right now) so that it's possible to do it properly, so that you don't skip important steps just because your app is so far down the development lifecycle that there isn't time/resource/technical skill to make it secure, so that you don't end up writing an app that has to be practically re-written from scratch later in order to secure it sufficiently.
• Where you have the Auth/Authz definitions, they're good but they're a bit oddly sat in the middle of the topic - you need to briefly introduce them (imagine the reader hasn't seen the other security topics that we have written - this is to give the key bits of info they need, as a developer rather than an ops person in a way that makes sense for them), and/or make them part of the same paragraph. Actually, you've replicated these sentences in the paragraph afterwards so maybe you can remove the first mentions of them anyway?
• When you say "the user", could you be more explicit (at least on first mention) and really spell out who you mean eg "the end-user of your application". "the user" is so vague and can mean multiple people in even the same context.
• Thanks for adding an example scenario. Can you frame it more towards a developer writing an app now? The current description is a nice example but it is talking about a larger system (which is what an ops person would care about) not a specific app within that system (which is what a developer would care about). A simple one might be writing an app like Bluepages (a company employee directory) for their company and while anyone in the company (but not outside) can access the details of all employees, only the employee and their direct manager can edit an employees profile in it (hence requiring some different permissions for employees vs managers). And it'd use the employee's company intranet account details to authenticate them through SSO, etc. Get an SME to work with you on this though to make sure it's technically plausible, and make sure to keep it simple.
• Diagram - thanks - can you take a look at the diagram in the Authentication topic and take that as a basis and then adapt it for this topic (so we have consistency) - probably just the same as that but annotate it in some way with where the weaknesses are that a developer should be concerned about securing when developing an app (not everything is within the control of a developer - eg as you know from your other topics, a developer might need to set up an OIDC provider for testing building JWTs whilst developing the app but that wouldn't be what is used to build JWTs in production).
• I'm not sure the development/production headings are necessarily that helpful, or not at the top level of the topic like this. Focus on the developer developing an app and the considerations they need to make, then either call out where they need to do something different for production (as in my outline above), or just have a section at the end called "hardening your application for production" or something. Don't worry about production for a start though.

[ManasiGandhi]

@lauracowen I worked on your review. Here is the link to the draft https://draft-openlibertyio.mybluemix.net/docs/20.0.0.10/securing-cloud-native-microservices.html

• [x] Can you move this topic into the Development section of the navigation instead of the Security section? This is the only security-related topic that will be in the Development section (all the other security-related topics are for more of an ops audience).

• [x] First paragraph, I think "to prevent unauthorized access to your application" is the reason for the first sentence in that paragraph, not the reason for the second sentence. The reason why you should secure your app earlier rather than later is (and I can't think how to phrase this properly right now) so that it's possible to do it properly, so that you don't skip important steps just because your app is so far down the development lifecycle that there isn't time/resource/technical skill to make it secure, so that you don't end up writing an app that has to be practically re-written from scratch later in order to secure it sufficiently.

• [x] Where you have the Auth/Authz definitions, they're good but they're a bit oddly sat in the middle of the topic - you need to briefly introduce them (imagine the reader hasn't seen the other security topics that we have written - this is to give the key bits of info they need, as a developer rather than an ops person in a way that makes sense for them), and/or make them part of the same paragraph. Actually, you've replicated these sentences in the paragraph afterwards so maybe you can remove the first mentions of them anyway?

• [x] When you say "the user", could you be more explicit (at least on first mention) and really spell out who you mean eg "the end-user of your application". "the user" is so vague and can mean multiple people in even the same context. (I added "users of your application" as "end-user" is not allowed in the terminology)

• [x] Thanks for adding an example scenario. Can you frame it more towards a developer writing an app now? The current description is a nice example but it is talking about a larger system (which is what an ops person would care about) not a specific app within that system (which is what a developer would care about). A simple one might be writing an app like Bluepages (a company employee directory) for their company and while anyone in the company (but not outside) can access the details of all employees, only the employee and their direct manager can edit an employees profile in it (hence requiring some different permissions for employees vs managers). And it'd use the employee's company intranet account details to authenticate them through SSO, etc. Get an SME to work with you on this though to make sure it's technically plausible, and make sure to keep it simple. (Worked with Teddy Torres on the example scenario)

• [x] Diagram - thanks - can you take a look at the diagram in the Authentication topic and take that as a basis and then adapt it for this topic (so we have consistency) - probably just the same as that but annotate it in some way with where the weaknesses are that a developer should be concerned about securing when developing an app (not everything is within the control of a developer - eg as you know from your other topics, a developer might need to set up an OIDC provider for testing building JWTs whilst developing the app but that wouldn't be what is used to build JWTs in production). (link to the diagram https://ibm.enterprise.slack.com/files/WJ02BA266/F01ABQD1J9X/image.png)

• [x] I'm not sure the development/production headings are necessarily that helpful, or not at the top level of the topic like this. Focus on the developer developing an app and the considerations they need to make, then either call out where they need to do something different for production (as in my outline above), or just have a section at the end called "hardening your application for production" or something. Don't worry about production for a start though.

[ManasiGandhi]

New link to the draft https://draft-openlibertyio.mybluemix.net/docs/20.0.0.10/securing-cloud-native-microservices.html

[ManasiGandhi]

Updated draft link https://draft-openlibertyio.mybluemix.net/docs/20.0.0.11/securing-cloud-native-microservices.html

[lauracowen]

Hi Manasi,

I just saw Karen's list of topics that you'd come up with as a team (sorry @chirp1 - not sure how I missed that before). I think maybe we can use some of that to give some more depth to this topic, so that it doesn't just become a list of links to other security topics.

Maybe frame the topic as providing best practice on how to design a secure application for a microservices architecture. Always from the developer's perspective (for this topic) though:

• Defence in Depth- Multiple layers of security - a quick intro to this as context but then specifically focushow the application's security contributes to that (the way security is implemented within the Java code of an app; the APIs used, eg MP JWT and tokens; the use of SSO), then maybe touch on app configuration and point them to the hardening topic for more detail on that part.
• Differences in security going from a monolithic to a microservice architecture - yes, what does the app developer need to consider here? (eg in a microservices architecture, the app is more modular and so has to request/return info back and forth between individual services instead of within a single monolithic app. As soon as data is passed between the services instead of within a single service, it's exposed to potentially being intercepted, so that's one difference in security requirements maybe. Find out if there are others.)
• Using an API gateway as a single entry point for all requests - is this a best practice? if so, then yes, explain what this means in practice and why.
• Monitoring and tracing for security - This doesn't really sound like a developer-focused concern (other than that they'd enable metrics and tracing in the app). So maybe not so much on this.

I think you'll need solid support from an SME to write this. Not necessarily someone from the security team if you can find someone with some experience at writing secure microservices. It might be worth arranging a chat with YK Chang for a first pass at what he'd consider important to mention. You could then find someone in the security team, maybe, to help write it.

I think the success of writing this topic will hinge largely on finding a good person (SME) to work with. And then ensuring that you can explain it clearly and well (regardless of how the SME expresses the info).

So you'll need to do some background research and self-learning (eg try doing the security-related guides but note that the JWT guide is about to be updated to something easier to read and more usable to follow - Charlotte might know when it's published as she edited it recently). Ideally, get some basic knowledge before talking to the SMEs so that you can put together a list of questions to ask them. The guides will probably explain or demonstrate some concepts relevant to the items on Karen's list above, which might help with both your understanding and what to ask SMEs.

This will be challenging (in a good way - and will give you a good knowledge basis that will generally be applicable across various IBM projects/products you might work on) so it might be something to work collaboratively on with another writer, at least at the start. It may be that it can provide a doc topic here but also the basis of a blog post or article on IBM Developer too in future.

[ManasiGandhi]

I'm planning to work on this issue later based on a discussion during OL scrum.