User registries

[dmuelle]

This topic combines LDAP #962 and Basic #892 registry topics into a single topic, per strategist recommendation.

All content was previously SME & peer reviewed in those issues, with comments from reviewers there. No substantial changes to the content other than a new short description.

[dmuelle]

@lauracowen here's the new combined topic for LDAP and Basic registries. No new content, just combined and reorganized. Let me know if any further edits are needed before I send for Karen's review. Thanks

https://draft-openlibertyio.mybluemix.net/docs/ref/general/#user-registries-application-security.html

[lauracowen]

• In the intro, can you give the examples of "social media providers or ...(LDAP) registry." - LDAP is quite "on-prem" (I think). My understanding anyway is that LDAP is used for registries like our Bluepages, which is fine for apps within a company's firewall but you'd use something hosted in the cloud for external end-users like banking customers accessing their online banking (eg an external social media provider (maybe not for banking!), or a service like OpenShift's SSO thing...maybe, don't quote that as I'm not sure how the user registries work with that). But verify with someone who would know.
• Hmm, actually, maybe there needs to be a mention first of the fact that apps can 'outsource' their user registry management to, say, social media providers like Google or Facebook so that end-users of apps can log in using their existing social media credentials. (that's the primary approach we talk about - easier for developers and not reliant on in-house maintenance of it). But, when you need to use an existing company user registry (eg LDAP of all company employees). And, then in test environments, app developers can optionally set up a basic file-based user reg. for testing purposes to simplify etc etc.
• In the LDAP section, maybe briefly acknowledge that you'd probably be using LDAP if your company already has an LDAP registry set up (eg of all the company employees). I'm not sure if it's worth mentioning the setence about "many kinds of LDAP servers exist" as that's unlikely (I think) to be within the developer's control - they'll just use what they get - or should go find that out elsewhere if they've been asked to set one up (though I'm not sure that would be an app developer task).
• There's a dodgy link in the last para of the LDAP section - it's not rendered.

Otherwise, looks good.

[dmuelle]

Updated the draft:

• In the intro, can you give the examples of "social media providers or ...(LDAP) registry." - LDAP is quite "on-prem" (I think). I talked with Jesse VH & Teddy Torres and added a little more info to the intro and LDAP section to clarify, see what you think
• Hmm, actually, maybe there needs to be a mention first of the fact that apps can 'outsource' their user registry management to, say, social media providers like Google or Facebook so that end-users of apps can log in using their existing social media credentials. added a bit to the intro to clarify
• In the LDAP section, maybe briefly acknowledge that you'd probably be using LDAP if your company already has an LDAP registry set up (eg of all the company employees). I'm not sure if it's worth mentioning the setence about "many kinds of LDAP servers exist" updated
• There's a dodgy link in the last para of the LDAP section - it's not rendered. fixed

[lauracowen]

• Yes, I like the structure of that intro - it's really clear what you're saying now.
• I assume they're happy with saying/implying that microservices often use social media providers? (I have no idea if that's strictly true or whether they might use some other SSO service.)
• would it make sense for the file name to be just user-registries.adoc? Not sure it needs to be so long but it's up to you.

Other than that assertion (which I don't know the answer to), I'm happy with this and will sign it off. Thanks.

[dmuelle]

• Although I used Google and face book as examples, the sentence says "microservice-based applications in production often run on an application server that delegates identity management to a single sign-on provider, such as..." rather than social media. I chose Google and FB because they are easily recognizable than and don't really require any explanation. I could use a different example or leave the example out if it's misleading. The idea being that most of the time they're using some SSO, not to say which particularly.
• Leaving the filename as is ftm because we've already updated a number of links to it. I can change if needed

[dmuelle]

new draft URL:https://draft-openlibertyio.mybluemix.net/docs/20.0.0.11/user-registries-application-security.html

[dmuelle]

Issues fixed in new editing pass:

• replace references to "admin" with "administrator" so that term is used consistently throughout- both terms were used previously. Per Developing Quality Technical Information (DQTI) CH 6: Clarity: USE TECHNICAL TERMS CONSISTENTLY AND APPROPRIATELY
• fix typo "applicationneeds"
• The simplest option for configuring a basic user registry-> The simplest way to configure a basic user registry
• replace link to Password encryption with link to securityUtility encode command- DQTI ch 10 Retrievability:Link appropriately
• LDAP registries and the Social Media Login feature->LDAP authentication with social media credentials DQTI ch 3 "Write user-oriented task topics, not function-oriented task topics"
• In cases where user and group information is spread across multiple registries, Open Liberty can federate distributed user information in a unified registry, with a continuous store of information-> In cases where user and group information is spread across multiple registries, federation enables Open Liberty to use distributed user information in a unified manner, with a continuous store of information. DQTI Ch8- Use active and passive voice appropriately.
• You can adjust the configuration of federated registries by enabling the Federated User Registry feature and configuring the federatedRepository element ->You can control the contents of federated registries configuring the federatedRepository element. DQTI ch7 Use specific language

[jvanhill]

My findings:

Basic user registries:

Although this registry is not secure enough for production environments

• Are we sure we want to say this? Seems if they encrypt their passwords it should be secure. Would need @arkarkala to comment.

User Password Security

You can obfuscate the passwords

• Not only obfuscate, but also encrypt.

Federated user registries:

they are federated by default when you enable both the Application Security feature and the Federated User Registry feature

• Only need federated user registry feature.

However, basic user registries that are configured with the QuickStart security option cannot be federated with other registries

• basic registries are not configured with quickstart security. They are two separate registries. What you want to say that quick start security registries cannot be federated.

[dmuelle]

@jvanhill thanks for reviewing. I made the following changes to the draft based on your comments:

Although this registry is not secure enough for production environments

Are we sure we want to say this? Seems if they encrypt their passwords it should be secure. Would need @arkarkala to comment.

In @jtmulvey ppt Intro to Security in WebSphere Liberty he says the the Basic registry is for development only "We wouldn't expect to see someone using a basic registry in production". But maybe I put too fine a point on it. I've revised this sentence to say
Although this registry is not intended for production environments.. Thoughts? @arkarkala ?

---

You can obfuscate the passwords

Not only obfuscate, but also encrypt.

I changed this to You can hash or encrypt the passwords in your basic user registry, which should cover all the formats available from the securityUtility encode command- xor, aes, and hash.

---

they are federated by default when you enable both the Application Security feature and the Federated User Registry feature

• Only need federated user registry feature. fixed

However, basic user registries that are configured with the QuickStart security option cannot be federated with other registries

• basic registries are not configured with quickstart security. They are two separate registries. What you want to say that quick start security registries cannot be federated. fixed

[chirp1]

@dmuelle Hi David,
Here are my comments:

• Mention custom user registries and federated user registries in the second paragraph since you discussed the other user registries there.
• For "user group" versus "group", use the same term consistently across topics. Use "group" instead of "user group".https://draft-openlibertyio.mybluemix.net/docs/20.0.0.11/server-configuration-hardening.html My belief is that "group" is the correct term.
• You link to https://draft-openlibertyio.mybluemix.net/docs/20.0.0.11/reference/feature/appSecurity-3.0.html I notice in this feature "For more information, see Basic user registries for application development. " The link is broken. Is the link supposed to go to your User registries topic? I don't think we need the link there. I don't see other features linking back to reference information.
• Work in "quickStartSecurity element" into the Quickstart security section.
• Change "you might need to configure it" to "configure it".
• You might explain the difference between a registry and a repository, similar to https://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_sec_cust_select.html
• Do you have an OL link at this point for "the UserRegistry interface."? The link currently goes to a KC javadoc topic.
• I'd suggest putting the custom user registries section before the federated user registries section since you discuss custom user registries in the federated user registries section. However, I do see that you mention federated user registries in the custom user registries section. You could possibly add a link on the "federated" word to the "Federated user registries" section.
• See if you can reword "need" out of at least some of the sentences. For instance, instead of "If your application needs to regulate access ", you can reword it to "If your application regulates access ". Check your other topics and reword the word "need" to something else as much as possible.
• In the "Custom user registries" section, you said "basic or LDAP user registry, " in the first paragraph, but in the second paragraph, you added in "federated" and said "basic, LDAP or federated user registry '. would you want to add "federated to the first paragraph? Also, I think the second paragraph is a little redundant with the first paragraph.

[dmuelle]

Thanks for reviewing @chirp1, I made the following changes per your review:

• Mention custom user registries and federated user registries in the second paragraph since you discussed the other user registries there.

• For "user group" versus "group", use the same term consistently across topics. **changed to just "group" in all instances

• You link to https://draft-openlibertyio.mybluemix.net/docs/20.0.0.11/reference/feature/appSecurity-3.0.html I notice in this feature "For more information, see Basic user registries for application development. " The link is broken. Is the link supposed to go to your User registries topic? I don't think we need the link there. I don't see other features linking back to reference information this link is in Richards app security example. I'm not sure why he put it there but since it was broekn anyway I pulled down his branch and removed it

• Work in "quickStartSecurity element" into the Quickstart security section.

• Change "you might need to configure it" to "configure it".

• You might explain the difference between a registry and a repository

• Do you have an OL link at this point for "the UserRegistry interface."? Not yet- the liberty javadoc is not available on the OL website. However, this entire section will be updated or replaced once Richards custom user registry task publishes. opened Update custom user registry section of User registry doc once new task publishes #2890 to track that

• I'd suggest putting the custom user registries section before the federated user registries section since you discuss custom user registries in the federated user registries section. revised

• See if you can reword "need" out of at least some of the sentences removed all instances

• In the "Custom user registries" section, you said "basic or LDAP user registry, " in the first paragraph, but in the second paragraph, you added in "federated" and said "basic, LDAP or federated user registry '. would you want to add "federated to the first paragraph? Also, I think the second paragraph is a little redundant with the first paragraph.
  revised

[chirp1]

@dmuelle Hi David,

• A little tweak: Change "you can configure custom user registry." to "you can configure a custom user registry.". <= Add "a".
• For "you can define a custom user registry or a custom user repository." , is that in the server.xml file? you might want to mention where one would add the definition. And this comment ties in with "Customized attributes are any attributes that are not already defined in the current schema.". What is a schema? Is it the info in the server.xml file, for instance?

[dmuelle]

Thanks @chirp1, I made the following changes based on your review:

• A little tweak: Change "you can configure custom user registry." to "you can configure a custom user registry.". <= Add "a".

• For "you can define a custom user registry or a custom user repository." , is that in the server.xml file? **yes, you specify a user feature for the custom reg or repo in your server.xml. We don't have any doc in Open Liberty for user features or OSGi at the moment, and the process is not well documented in the Liberty KC either. However, this information will be replaced once Developing a custom user registry with BELLS #2418 publishes

• "Customized attributes are any attributes that are not already defined in the current schema.". What is a schema? Is it the info in the server.xml file, for instance?

I updated this to be "server schema" because I think server.xml isn't specific enough. For instance, if there were no group name attributes in your server.xl file, and you defined one, it would not constitute a custom attribute, because group name is already defined as an option for an open liberty server. However, if you wanted to add an attribute that was not even offered as a part of the existing attribute options, that would be a custom attribute. So "schema" here should refer to the blueprint for existing server options, like an XML schema. Does that work?

[chirp1]

@dmuelle Hi David, Thanks for the explanations. The updates look good. Moving to Ready to Publish.

[dmuelle]

moved to vNext to publish with 20.0.0.11. Closing this issue.