[JBoss JIRA] (ELY-444) AuthorizationIdentity and PermissionMapper
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-444:
---------------------------------
BTW The way you do this is via the org.wildfly.security.auth.server.SecurityIdentity#intersectWith method. You can never increase the permission set of an identity with this method, but you can narrow it.
> AuthorizationIdentity and PermissionMapper
> ------------------------------------------
>
> Key: ELY-444
> URL: https://issues.jboss.org/browse/ELY-444
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Realms
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta6
>
>
> When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm. But now as the API has evolved it is clear that the permission mapper will need access to more information. The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper.
> In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things. Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)
by Ladislav Thon (JIRA)
Ladislav Thon created WFCORE-1517:
-------------------------------------
Summary: can't start server with configuration file from EAP 6.4.7 (and above)
Key: WFCORE-1517
URL: https://issues.jboss.org/browse/WFCORE-1517
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Ladislav Thon
Assignee: Brian Stansberry
Priority: Blocker
When trying to run EAP 7 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
{code}
14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
Message: Unexpected element '{urn:jboss:domain:1.8}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
... 3 more
14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1517?page=com.atlassian.jira.plugi... ]
Ladislav Thon updated WFCORE-1517:
----------------------------------
Description:
When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
{code}
14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
Message: Unexpected element '{urn:jboss:domain:1.8}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
... 3 more
14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
was:
When trying to run EAP 7 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
{code}
14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
Message: Unexpected element '{urn:jboss:domain:1.8}server'
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
... 3 more
14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}
This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
> can't start server with configuration file from EAP 6.4.7 (and above)
> ---------------------------------------------------------------------
>
> Key: WFCORE-1517
> URL: https://issues.jboss.org/browse/WFCORE-1517
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Priority: Blocker
>
> When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
> {code}
> 14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
> Message: Unexpected element '{urn:jboss:domain:1.8}server'
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> ... 3 more
> 14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (ELY-444) AuthorizationIdentity and PermissionMapper
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-444:
---------------------------------
I think we're already well-equipped for custom providers now: the security domain can now transform the SI to have any arbitrary permission enforcement model, even beyond permission mappers.
> AuthorizationIdentity and PermissionMapper
> ------------------------------------------
>
> Key: ELY-444
> URL: https://issues.jboss.org/browse/ELY-444
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Realms
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta6
>
>
> When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm. But now as the API has evolved it is clear that the permission mapper will need access to more information. The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper.
> In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things. Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JGRP-2058) Probe: add bundler type at runtime
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2058?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2058:
--------------------------------
The method to replace the bundler is {{TP.bundler(String type)}}. Examples:
* {{probe.sh op=UDP.bundler["sender-sends']}}
* {{probe.sh op=UDP.bundler["com.widgets.MyCustomBundler"]}}
> Probe: add bundler type at runtime
> ----------------------------------
>
> Key: JGRP-2058
> URL: https://issues.jboss.org/browse/JGRP-2058
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> Add a method to shutdown the old Bundler implementation in TP and create and start a new one. Argument should either be {{bundler_type}} or the fully qualified classname of a {{Bundler}} impl, so that unknown bundlers can also be created as long as the code is on the classpath.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-6101) Removing of non-existent policy-module finishes with outcome success
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFLY-6101?page=com.atlassian.jira.plugin.... ]
Bartosz Spyrko-Śmietanko reassigned WFLY-6101:
----------------------------------------------
Assignee: Bartosz Spyrko-Śmietanko (was: Brian Stansberry)
> Removing of non-existent policy-module finishes with outcome success
> --------------------------------------------------------------------
>
> Key: WFLY-6101
> URL: https://issues.jboss.org/browse/WFLY-6101
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 10.0.0.Final
> Reporter: Ondrej Lukas
> Assignee: Bartosz Spyrko-Śmietanko
> Priority: Minor
>
> In case when non-existent policy-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (ELY-444) AuthorizationIdentity and PermissionMapper
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor edited comment on ELY-444 at 4/29/16 8:08 AM:
---------------------------------------------------------
Recently, I've been working on a Authorization API. I think we could review what I did and see if we can reuse something or how to adapt it to Elytron. If you find it useful.
I think authorization can be completely decoupled from the authentication subsystem, where the concept of an Identity is abstract and simple enough to just provide the necessary information (basically, the claims/attributes) to evaluate authorization policies and grant/deny permissions. Beside the identity, we should also consider environment/execution information to base authorization decisions. In this case, it will allow us to support different access control mechanisms and combinations of them.
An SPI should also be interesting in order to plug different Policy Providers, where we could define policies using different strategies. From simple RBAC to more complex policies using a script language.
was (Author: pcraveiro):
Recently, I've been working on a Authorization API. I think we could review what I did and see if we can reuse something or how to adapt it to Elytron. If you find it useful.
I think authorization can be completely decoupled from the authentication subsystem, where the concept of an Identity is abstract and simple enough to just provide the necessary information to evaluate authorization policies and grant/deny permissions. Beside the identity, we should also consider environment/execution information to base authorization decisions. In this case, it will allow us to support different access control mechanisms and combinations of them.
An SPI should also be interesting in order to plug different Policy Providers, where we could define policies using different strategies. From simple RBAC to more complex policies using a script language.
> AuthorizationIdentity and PermissionMapper
> ------------------------------------------
>
> Key: ELY-444
> URL: https://issues.jboss.org/browse/ELY-444
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Realms
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta6
>
>
> When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm. But now as the API has evolved it is clear that the permission mapper will need access to more information. The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper.
> In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things. Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (ELY-444) AuthorizationIdentity and PermissionMapper
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor commented on ELY-444:
--------------------------------
Recently, I've been working on a Authorization API. I think we could review what I did and see if we can reuse something or how to adapt it to Elytron. If you find it useful.
I think authorization can be completely decoupled from the authentication subsystem, where the concept of an Identity is abstract and simple enough to just provide the necessary information to evaluate authorization policies and grant/deny permissions. Beside the identity, we should also consider environment/execution information to base authorization decisions. In this case, it will allow us to support different access control mechanisms and combinations of them.
An SPI should also be interesting in order to plug different Policy Providers, where we could define policies using different strategies. From simple RBAC to more complex policies using a script language.
> AuthorizationIdentity and PermissionMapper
> ------------------------------------------
>
> Key: ELY-444
> URL: https://issues.jboss.org/browse/ELY-444
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, Realms
> Reporter: David Lloyd
> Fix For: 1.1.0.Beta6
>
>
> When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm. But now as the API has evolved it is clear that the permission mapper will need access to more information. The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper.
> In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things. Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (DROOLS-1150) Problems found by FindBugs in drools-core
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-1150:
-------------------------------------
Summary: Problems found by FindBugs in drools-core
Key: DROOLS-1150
URL: https://issues.jboss.org/browse/DROOLS-1150
Project: Drools
Issue Type: Bug
Affects Versions: 7.0.0.Final
Reporter: Tibor Zimányi
Assignee: Mario Fusco
Attachments: findBugsDroolsCore.ods, FindBugsResult_4_29_16-drools-core.html
I ran FindBugs analysis on drools-core module on master. There is 880 warnings in the report. So a pretty decent number. I picked some for start. See attachments. Also we should focus on concurrency warnings. You can find them in the report under "Multithreaded correctness Warnings" section.
For better description of the warnings, you can install FindBugs-IDEA plugin and run the analysis in IDE. Each warning has some short description, sometimes with a link pointing to an article or more detailed info about the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months