[JBoss JIRA] (ELY-904) Logout support for HTTP-based authentication mechanisms
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor updated ELY-904:
---------------------------
Description:
I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.
was:
I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Logout support for HTTP-based authentication mechanisms
> -------------------------------------------------------
>
> Key: ELY-904
> URL: https://issues.jboss.org/browse/ELY-904
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.1.0.Beta21
> Reporter: Pedro Igor
> Assignee: Pedro Igor
>
> I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
> Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
> The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
> Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ELY-904) Logout support for HTTP-based authentication mechanisms
by Pedro Igor (JIRA)
Pedro Igor created ELY-904:
------------------------------
Summary: Logout support for HTTP-based authentication mechanisms
Key: ELY-904
URL: https://issues.jboss.org/browse/ELY-904
Project: WildFly Elytron
Issue Type: Enhancement
Components: HTTP
Affects Versions: 1.1.0.Beta21
Reporter: Pedro Igor
Assignee: Pedro Igor
I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests.
Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases.
The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFCORE-1987) Create request/response reporting mechanism
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ]
Bartosz Baranowski commented on WFCORE-1987:
--------------------------------------------
[~brian.stansberry] I think I figured out the reason for silent treatment of inactive profile.
Just to clarify, I run existing domain.xml conf/xml, with some small change - Ive added worker 'xxx'.
In in CLI
{noformat}
cd profile=default/subsystem=undertow/server=default-server/http-listener=default
:write-attribute(name=worker,value=xxx)
{noformat}
When operation hit controller primaryAnswer is set to value from step with PrepareStepHandler: {"outcome" => undefined}. (A1)
https://github.com/wildfly/wildfly-core/blame/master/controller/src/main/...
This value is the same for next step, with DomainFinalResultHandler.
There is another value created in https://github.com/wildfly/wildfly-core/blame/master/host-controller/src/... (A2).
The A2 is actually one that is being edited in WriteAttributeHandler - this one contain proper answer to operation.
When DomainFinalResultHandler kicks in, it gets both values:
- A1: https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m...
- A2: https://github.com/wildfly/wildfly-core/blob/master/host-controller/src/m...
Im kind of trying to figure out what getDomainResults method is supposed to parse, but all it return is "undefined" regardless of any content (outcome->success and other nodes) in A2, and populate it into A1.
If profile is active, whole thing is saved by "serverResults" which is not empty in this case and contain ~same result as A1.
Any thoughts?
> Create request/response reporting mechanism
> -------------------------------------------
>
> Key: WFCORE-1987
> URL: https://issues.jboss.org/browse/WFCORE-1987
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Reporter: Radim Hatlapatka
> Assignee: Bartosz Baranowski
> Labels: downstream_dependency
>
> In certain cases it is useful to send back, to client, some sort of context information about the outcome of operation. For instance, when change in configuration warrants another one and without it, after reload/restart server could not operate properly. For instance JBEAP-7284.
> Scope of this enhancement are:
> a) way to send back information
> b) control level of "information" - just like in case of loggers
> a) Information will be sent in response headers, under "warnings" key. Each entry, "warning" will contain operation, address, level/severity and i18n string with proper ID.
> b) default level threshold would be "WARNING", if user requires more detailed information, he can request it via operation-headers->warninig-level
> Example:
> {noformat}
> {
> "outcome" => "success",
> "response-headers" => {
> "warnings" => [
> {
> "warning" => "WFLYCTL0436: Couldn't convert 'XXX' into proper warning level, threshold falling back to 'ALL'. Possible values: SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST",
> "level" => "ALL",
> "operation" => {
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("http-listener" => "default")
> ],
> "operation" => "write-attribute"
> }
> },
> {
> "warning" => "WFLYUT0090: Worker used in http-listener: 'puppet-master', must be used in remoting subsystem.",
> "level" => "WARNING",
> "operation" => {
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("http-listener" => "default")
> ],
> "operation" => "write-attribute"
> }
> }
> ],
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2252:
-------------------------------------
Description:
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
AttributeDefinition should reject the combination of a default value and required=true in its constructor.
I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
was:
If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
AttributeDefinition should reject this combination in its constructor.
I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-2252
> URL: https://issues.jboss.org/browse/WFCORE-2252
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject the combination of a default value and required=true in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2252:
-------------------------------------
Fix Version/s: 4.0.0.Beta1
Moving to consideration in WildFly Core 4. Too disruptive at this stage for 3.
> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-2252
> URL: https://issues.jboss.org/browse/WFCORE-2252
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject this combination in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (JGRP-1539) NAKACK2: xmit_interval sometimes triggers unneeded retransmissions
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1539?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1539:
---------------------------
Description:
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message.
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
- At time T1009, messages 6-19 are received
Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Had the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.
The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
Another reason is also that the message bundler on the sender side might send messages in random order (see link below).
SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.
was:
In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message.
Example:
- Messages 1,2,3,4,5 are received at time T0 (in ms)
- At time T1000, message 20 is received
- At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
- At time T1009, messages 6-19 are received
Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Has the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.
The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
Another reason is also that the message bundler on the sender side might send messages in random order (see link below).
SOLUTION:
Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.
> NAKACK2: xmit_interval sometimes triggers unneeded retransmissions
> ------------------------------------------------------------------
>
> Key: JGRP-1539
> URL: https://issues.jboss.org/browse/JGRP-1539
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> In NAKACK2 (and UNICAST2 as well), a timer task kicks in every xmit_interval milliseconds. If we just added a message out of order, then the retransmit task might send a spurious retransmission message.
> Example:
> - Messages 1,2,3,4,5 are received at time T0 (in ms)
> - At time T1000, message 20 is received
> - At time T1001, the retransmit task kicks in and asks the sender for retransmission of messages [6-19]
> - At time T1009, messages 6-19 are received
> Problem: the out-of-order message 20 was received just before the retransmit task kicked in. Had the task waited for another 9 ms (until time T1009), the retransmission would not have been necessary.
> The underlying cause is that the retransmit tasks handles recently added gaps the same as gaps added before xmit_interval, as we don't maintain a timestamp for added messages.
> Another reason is also that the message bundler on the sender side might send messages in random order (see link below).
> SOLUTION:
> Investigate how to change the retransmission task such that it excludes gaps created within the last xmit_interval ms.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (ELY-903) Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/ELY-903?page=com.atlassian.jira.plugin.sy... ]
Ondrej Lukas updated ELY-903:
-----------------------------
Attachment: print-roles.war
> Missing some role assignment for Elytron ldap-realm when role and user are members of the same role
> ---------------------------------------------------------------------------------------------------
>
> Key: ELY-903
> URL: https://issues.jboss.org/browse/ELY-903
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta21
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Attachments: print-roles.war
>
>
> In case when role recursion is configured for ldap-realm and given LDAP includes some role which has member some user and also another role, then some roles are intermittently not assigned. See Steps to Reproduce for more details about configuration.
> Most important part of ldif for reproduction is following:
> {code}
> dn: cn=R1,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R1
> member: uid=jduke,ou=People,dc=jboss,dc=org
> description: the R1 group
> dn: cn=R2,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R2
> member: uid=jduke,ou=People,dc=jboss,dc=org
> member: cn=R1,ou=Roles,dc=jboss,dc=org
> description: the R2 group
> dn: cn=R3,ou=Roles,dc=jboss,dc=org
> objectclass: top
> objectclass: groupOfNames
> cn: R3
> member: cn=R2,ou=Roles,dc=jboss,dc=org
> description: the R3 group
> {code}
> User jduke is direct member of roles R1 and R2. However role R2 is also member of role R1. In case when {{ldap-realm.identity-mapping.attribute-mapping.role-recursion}} is configured to {{2}}, then sometimes only roles R1, R2 and R3 are assigned (and role R4 is missing).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months