Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WFCORE-5740] Add the ability to ignore unavailable realms for a distributed-realm #454

Merged
merged 5 commits into from
May 26, 2023
Merged

[WFCORE-5740] Add the ability to ignore unavailable realms for a distributed-realm #454

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
9f4d223
[WFCORE-5740] Add the ability to ignore unavailable realms for a dist…
lvydra Feb 7, 2022
cae4c99
[WFCORE-5740] Integration tests
lvydra Feb 8, 2022
c300854
[WFCORE-5740] SecurityRealmUnavailableEvent emitting
lvydra Feb 8, 2022
88d44e1
[WFCORE-5740] Documentation and Release Note Content
lvydra Feb 10, 2022
85a9f9c
[WFCORE-5740] Fix
lvydra Feb 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions ...n/WFCORE-5740-ability-to-ignore-unavailable-realms-for-a-distributed-realm.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
= [WFCORE-5740] Add the ability to ignore unavailable realms for a distributed-realm
:author: Lukas Vydra
:email: [email protected]
:toc: left
:icons: font
:idprefix:
:idseparator: -

== Overview
A distributed-realm is made up of a list of realms. Each realm in the list is attempted until we either find the user or run out of realms.
If a realm happens to be unavailable, we currently stop searching altogether. This is undesirable if the user could have been found in a subsequent realm.

This enhancmend will add an ignore-unavailable-realms boolean attribute to a distributed-realm to allow users to specify that the search should continue on to the next realm if a realm happens to be unavailable.

** Example configuration:

```
/subsystem=elytron/distributed-realm=distributedRealm:add(realms=[realm1, realm2], ignore-unavailable-realms=true)
```

== Issue Metadata

=== Issue
* https://issues.redhat.com/browse/WFCORE-5740[WFCORE-5740]


=== Related Issues

* https://issues.redhat.com/browse/ELY-2305[ELY-2305]
* https://issues.redhat.com/browse/EAP7-1862[EAP7-1862]

=== Dev Contacts

* mailto:{email}[{author}]

=== QE Contacts
* mailto:{email}[{author}]

=== Testing By
[ ] Engineering

[x] QE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lvydra Since you'll be writing tests for the WildFly Elytron / Core / WildFly testsuites, we can select Engineering here.


=== Affected Projects or Components
* WildFly, Security, WildFly-Core, Elytron

=== Other Interested Projects

== Requirements

=== Hard Requirements
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about (a switch enabling) emitting SecurityRealmUnavailableEvent to the corresponding SecurityDomain, like in case of failover-realm? See https://github.com/wildfly/wildfly-proposals/pull/261/files#diff-91dfd08fb2d5ac316c73e22e73a78b8816d43bc21c0cd707a6ba075fb8a65f9bR64

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @OndrejKotek , thank you for your review. To be honest I'm not sure if adding another attribute isn't a bit out of the issue scope.

Copy link

@OndrejKotek OndrejKotek Feb 8, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean the event will be emitted, no option to disable it? Are there some requirements from the user side (as this RFE was brought by users AFAIK)? My suggestion aims to keep consistency with the failover-realm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @OndrejKotek , added.


* It should be possible to configure an ```distributed-realm``` with the optional attribute ```ignore-unavailable-realms``` which
allow users to specify that the search should continue on to the next realm if a realm happens to be unavailable.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to mention that the default value for the ignore-unavailable-realms attribute will be false.


When ```ignore-unavailable-realms``` is set to true and realm happens to be unavailable, SecurityRealmUnavailableEvent will be emitted to the corresponding SecurityDomain.
This can be turned off by adding `emit-events` attribute and setting it to `false`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding this in! It would be good to clarify here that emit-events is a new, optional attribute that will be added and we should also specify what it defaults to.



=== Nice-to-Have Requirements

=== Non-Requirements

== Test Plan
WildFly integration tests will be added. Tests also will be added to the Elytron testsuite.

== Community Documentation

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Elytron documentation can be found here:
https://docs.wildfly.org/26/WildFly_Elytron_Security.html

The source for the documentation is in the WildFly repo:
https://github.com/wildfly/wildfly/tree/main/docs/src/main/asciidoc/_elytron

In the "Community Documentation" section, we should mention that documentation about the new attribute will be added to an appropriate section of the Elytron docs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A "Release Note" content section should also be added. As explained in design-doc-template.adoc, this section just includes a couple sentences that could be used when drafting the release notes for a release that includes this new feature.