docs: New landing page #853
Conversation
docs/content/_index.adoc
Outdated
| - authorizer: opa | ||
| ---- | ||
|
|
||
| The decision process can be controlled by each and every upstream service individually via rules, which heimdall can load from different sources, like e.g. from a `RuleSet` kubernetes resource. |
There was a problem hiding this comment.
Not sure if this is the best way to put this, the decision process isn't "controlled" by the upstream services, it's controlled by the user writing the rules.
Maybe something along the lines of "Create rules for each upstream and path you want to secure, loading them from a variety of sources such as Kubernetes custom resources, S3 buckets or regular files".
Also not sure about using the Kubernetes resource as the primary example, is it the most used configuration type?
There was a problem hiding this comment.
Replaced with your suggestion: "Create rules for each upstream and path you want to secure, loading them from a variety of sources such as Kubernetes custom resources, S3 buckets or regular files"
There was a problem hiding this comment.
Also not sure about using the Kubernetes resource as the primary example, is it the most used configuration type?
Me neither. Maybe adding an example for e.g. file system is worth it as well and making it clickable e.g. as tabs or alike.
There was a problem hiding this comment.
Yeah, a comparison like that might be nice
docs/content/_index.adoc
Outdated
|
|
||
| {{% seo title="Reduces the cognitive load of your team" %}} | ||
|
|
||
| By outsourcing authentication and authorization decisions to heimdall you can reduce the complexity of your code base, free resources and reduce the cognitive load of your team pretty much. |
There was a problem hiding this comment.
Not sure if "pretty much" is correct here, sounds a bit awkward. I'd either replace it with something like "substantially" or remove it.
There was a problem hiding this comment.
Yeah, you're right. Changed that based on your suggestion.
There was a problem hiding this comment.
Reasoning for adding that: I want to highlight that systems like heimdall can help reducing complexity. Actually, reducing is a wrong word. The complexity is there, but you can shift it, making it less problematic for the own code. Or even not having to deal with it at all. This already starts with the gained ability to decide how the service gets informed about the subject, and alike. All of that can make the implementation of the upstream service simpler and also much easier to test.
There was a problem hiding this comment.
Definitely agree with the content and I'd argue that if you're using a microservice architecture you are actually actively reducing complexity by centralizing it in one place.
docs/content/_index.adoc
Outdated
| * Use Common Expression Language to implement complex authorization logic within a pipeline | ||
| * Use existing authorization systems, like OpenFGA, Ory Keto, Open Policy Agent and many more. | ||
| * Use existing authentication systems supporting OpenID Connect or OAuth2 | ||
| * Combine existing authentication systems |
There was a problem hiding this comment.
This point might be worth merging with the pipeline one as "combining existing authentication systems" is nothing more than composing authentication steps in a pipeline.
Not sure about a good way to put it though, maybe adding examples for the kinds of composition possible would be useful.
Related issue(s)
Checklist
Description
When ready, it would update the current landing page with useful information and be hopefully appealing in sense of the layout.