[JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-5739:
-----------------------------------
{quote}I have just sent PR https://github.com/wildfly/wildfly/pull/9003 that fixes it (for me){quote}
I think you meant https://github.com/wildfly/wildfly/pull/9030 ;)
I checked the latest change and it looks quite good, but I must say I'm also not the WildFly internals specialist. But indeed, because registerSession is handled in the {{AuthenticationMechanism}}, it makes much more sense that the handler only uses one approach to set the groups/roles data, and then the mechanism copies this to all other places.
Perhaps it would be even cleaner if the handler only stored the raw data as set by the SAM via the callbacks in a private simple TLS variable, and then let the authentication mechanism install that in the 3 places you identified (i.e. including {{JbossSecurityContext}}). Now there may be the small weirdness that after calling the handler, but before returning from {{validateRequest}} the caller is sort of partially authenticated. But alas, that's unrelated to this particular PR.
Those 3 places to store the authentication data have been a frequent source of bugs. More than a handful of previous bugs has been related to those 3 not being kept in perfect sync. (This is incidentally also why for JSR 375 I really didn't want to introduce a JSR 375 specific place to store this same data, as it would mean yet another location that can get out of sync with whatever the container is using.)
I would like to thank the both of you again for helping out with these issues. Great work ;)
> Subject not populated with groups/roles when authenticated via JASPIC
> ---------------------------------------------------------------------
>
> Key: WFLY-5739
> URL: https://issues.jboss.org/browse/WFLY-5739
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR4
> Reporter: Arjan t
> Assignee: Darran Lofthouse
> Labels: jacc, jaspic
> Attachments: CustomAuth.zip, picketbox.zip
>
>
> After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails.
> For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role:
> {code:java}
> Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
>
> boolean hasAccess = Policy.getPolicy().implies(
> new ProtectionDomain(
> new CodeSource(null, (Certificate[]) null),
> null, null,
> subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
> ),
> new WebResourcePermission("/protected/Servlet", "GET"))
> ;
> {code}
> As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles.
> This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject":
> {code:java}
> String[] rolesArray = groupPrincipalCallback.getGroups();
> int sizeOfRoles = rolesArray != null ? rolesArray.length : 0;
>
> if( sizeOfRoles > 0 )
> {
> List<Role> rolesList = new ArrayList<Role>();
> for( int i = 0; i < sizeOfRoles ; i++ )
> {
> Role role = new SimpleRole( rolesArray[ i ] );
> rolesList.add( role );
> }
> RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList );
> // if the current security context already has roles, we merge them with the incoming roles.
> RoleGroup currentRoles = currentSC.getUtil().getRoles();
> // *** ROLES ARE ONLY SET HERE ***
> if (currentRoles != null) {
> currentRoles.addAll(roles.getRoles());
> }
> else {
> currentSC.getUtil().setRoles( roles );
> }
> }
> // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE
> // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO
> Subject subject = groupPrincipalCallback.getSubject();
> if( subject != null )
> {
> // if the current security context already has an associated subject, we merge it with the incoming subject.
> Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject();
> if (currentSubject != null) {
> subject.getPrincipals().addAll(currentSubject.getPrincipals());
> subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials());
> subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials());
> }
> currentSC.getSubjectInfo().setAuthenticatedSubject(subject);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6817) JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6817?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6817:
--------------------------------------
Assignee: Aaron Ogburn (was: Stuart Douglas)
> JASPICSecureResponseHandler.handleRequest throws NullPointerException when redirecting for CONFIDENTIAL transport guarantee
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6817
> URL: https://issues.jboss.org/browse/WFLY-6817
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Aaron Ogburn
> Assignee: Aaron Ogburn
> Fix For: 10.1.0.Final
>
> Attachments: standalone.xml
>
>
> JASPICSecureResponseHandler.handleRequest can throw a NPE for a redirect from a CONFIDENTIAL transport guarantee:
> {code}
> java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:35)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> This occurs because io.undertow.security.handlers.AbstractConfidentialityHandler generates the redirect before any JASPICContext is placed on the request, so JASPICSecureResponseHandler sees the null.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1590) Default parameter length validating ignores setMinSize(0)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1590?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1590:
------------------------------------------
This is a borderline RFE, as it's not clear how this functionality can consistently be provided. In the end the AD needs to call the user provided validator, and if that isn't configured correctly it will reject things regardless of how setMinSize()/setMaxSize() are set on the AD. For allowNull and allowExpressions we can get around that by not calling the provided validator for undefined or expression values but if there's a value we have to call the provided validator.
We can however improve things some by better handling cases where no validator is provided. I think that's your real goal here anyway.
> Default parameter length validating ignores setMinSize(0)
> ---------------------------------------------------------
>
> Key: WFCORE-1590
> URL: https://issues.jboss.org/browse/WFCORE-1590
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha1
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha4
>
>
> With the following attribute definition: -
> {code:java}
> static final SimpleAttributeDefinition REPLACEMENT = new SimpleAttributeDefinitionBuilder(ElytronDescriptionConstants.REPLACEMENT, ModelType.STRING, false)
> .setAllowExpression(true)
> .setMinSize(0)
> .setFlags(AttributeAccess.Flag.RESTART_RESOURCE_SERVICES)
> .build();
> {code}
> The following error is reported if an empty string is used as a parameter: -
> {noformat}
> [standalone@localhost:9990 /] ./subsystem=elytron/regex-name-rewriter=strip-realm:add(pattern="@ELYTRON.ORG", replacement="", replace-all=true)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0113: '' is an invalid value for parameter replacement. Values must have a minimum length of 1 characters",
> "rolled-back" => true
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1651) --keep-content is not taken into account when undeploying in domain mode
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1651:
--------------------------------------------
Summary: --keep-content is not taken into account when undeploying in domain mode
Key: WFCORE-1651
URL: https://issues.jboss.org/browse/WFCORE-1651
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
In domain mode, the --keep-content is not taken into account.
undeploy * --keep-content is identical as undeploy * The deployments are disabled and the references are removed from the server groups.
This should be changed to respect option semantic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-1158) NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
by Juan Carlos Garcia (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1158?page=com.atlassian.jira.plugi... ]
Juan Carlos Garcia commented on DROOLS-1158:
--------------------------------------------
Regarding your questions 1 and 2, this is an application which initially started with DROOLS 5 (and lots of internal patches), later on migrated to DROOL 6.0.1 (with less internal patches), and then migrated to DROOLS 6.3, is a long road to changes that but eventually we will.
Thanks!
> NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1158
> URL: https://issues.jboss.org/browse/DROOLS-1158
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: drools-reusepackage.tar, screenshot-1.png
>
>
> Having a set of DecisionTables which KnowledgePackages are cached in our application, after we detect a change in any of those XLS files, we build a KnowledgePackages from it, and then try to create a new KnowledgeBase with the new KnowledgePackages + the rest of the cached one that that were not modified, but it fails with a NPE internally in Drools (6.3.0 and 6.4.0)
> This is not a problem for the drools version (6.0.1.Final) that we currently uses using in production.
> After debugging and putting a breakpoint into the *MvelConstraint.java:619*, it shows that it is trying to look for a packageName which hasn't being loaded yet in the new kbase (but belong to others XLS).
> I have attached a project with a testcase that shows the problem, it has 2 DecisionTable which i had to cut down a little bit (from our real files) and removes some sensitive information (replacing some of text with FOO-BAR).
> {code}
> java.lang.NullPointerException
> at org.drools.core.rule.constraint.MvelConstraint.equals(MvelConstraint.java:619)
> at org.drools.core.reteoo.AlphaNode.internalEquals(AlphaNode.java:199)
> at org.drools.core.common.BaseNode.thisNodeEquals(BaseNode.java:194)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.getMatchingNode(CompositeObjectSinkAdapter.java:531)
> at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:121)
> at org.drools.core.reteoo.builder.PatternBuilder.buildAlphaNodeChain(PatternBuilder.java:332)
> at org.drools.core.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:313)
> at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:130)
> at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:78)
> at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:106)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1567)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1547)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:920)
> at org.drools.core.impl.KnowledgeBaseImpl.access$000(KnowledgeBaseImpl.java:117)
> at org.drools.core.impl.KnowledgeBaseImpl$1.run(KnowledgeBaseImpl.java:708)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:716)
> at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:705)
> at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:273)
> at org.drools.impl.adapters.KnowledgeBaseAdapter.addKnowledgePackages(KnowledgeBaseAdapter.java:62)
> at bug.demo.BugReloadableDecisionTableTest.addRuleSetToKnowledgeBase(BugReloadableDecisionTableTest.java:63)
> at bug.demo.BugReloadableDecisionTableTest.testReuseKnowledgePackage(BugReloadableDecisionTableTest.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-1158) NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
by Juan Carlos Garcia (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1158?page=com.atlassian.jira.plugi... ]
Juan Carlos Garcia commented on DROOLS-1158:
--------------------------------------------
Hi [~tari_manga], i forgot to include in my bug report that i was using JDK7:
{code}
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
Maven home: /usr/share/maven
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: /usr/lib/jvm/jdk-7-oracle-x64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-88-generic", arch: "amd64", family: "unix"
Tests in error:
testReuseKnowledgePackage(bug.demo.BugReloadableDecisionTableTest)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.012 s
[INFO] Finished at: 2016-07-13T16:42:44+02:00
[INFO] Final Memory: 15M/303M
[INFO] ------------------------------------------------------------------------
{code}
When using JDK8 the bug does not appear
{code}
>mvn -version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=1024m; support was removed in 8.0
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
Maven home: /usr/share/maven
Java version: 1.8.0_73, vendor: Oracle Corporation
Java home: /opt/java/jdk1.8.0_73/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.13.0-88-generic", arch: "amd64", family: "unix
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.836 s
[INFO] Finished at: 2016-07-13T16:43:08+02:00
[INFO] Final Memory: 15M/303M
[INFO] ------------------------------------------------------------------------
{code}
> NullpointerException when trying to reuse KnowledgePackage into a new KnowledgeBase
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1158
> URL: https://issues.jboss.org/browse/DROOLS-1158
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final, 6.4.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: drools-reusepackage.tar, screenshot-1.png
>
>
> Having a set of DecisionTables which KnowledgePackages are cached in our application, after we detect a change in any of those XLS files, we build a KnowledgePackages from it, and then try to create a new KnowledgeBase with the new KnowledgePackages + the rest of the cached one that that were not modified, but it fails with a NPE internally in Drools (6.3.0 and 6.4.0)
> This is not a problem for the drools version (6.0.1.Final) that we currently uses using in production.
> After debugging and putting a breakpoint into the *MvelConstraint.java:619*, it shows that it is trying to look for a packageName which hasn't being loaded yet in the new kbase (but belong to others XLS).
> I have attached a project with a testcase that shows the problem, it has 2 DecisionTable which i had to cut down a little bit (from our real files) and removes some sensitive information (replacing some of text with FOO-BAR).
> {code}
> java.lang.NullPointerException
> at org.drools.core.rule.constraint.MvelConstraint.equals(MvelConstraint.java:619)
> at org.drools.core.reteoo.AlphaNode.internalEquals(AlphaNode.java:199)
> at org.drools.core.common.BaseNode.thisNodeEquals(BaseNode.java:194)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.getMatchingNode(CompositeObjectSinkAdapter.java:531)
> at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:121)
> at org.drools.core.reteoo.builder.PatternBuilder.buildAlphaNodeChain(PatternBuilder.java:332)
> at org.drools.core.reteoo.builder.PatternBuilder.attachAlphaNodes(PatternBuilder.java:313)
> at org.drools.core.reteoo.builder.PatternBuilder.attachPattern(PatternBuilder.java:130)
> at org.drools.core.reteoo.builder.PatternBuilder.build(PatternBuilder.java:78)
> at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:108)
> at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
> at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
> at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:106)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1567)
> at org.drools.core.impl.KnowledgeBaseImpl.addRule(KnowledgeBaseImpl.java:1547)
> at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:920)
> at org.drools.core.impl.KnowledgeBaseImpl.access$000(KnowledgeBaseImpl.java:117)
> at org.drools.core.impl.KnowledgeBaseImpl$1.run(KnowledgeBaseImpl.java:708)
> at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:716)
> at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:705)
> at org.drools.core.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:273)
> at org.drools.impl.adapters.KnowledgeBaseAdapter.addKnowledgePackages(KnowledgeBaseAdapter.java:62)
> at bug.demo.BugReloadableDecisionTableTest.addRuleSetToKnowledgeBase(BugReloadableDecisionTableTest.java:63)
> at bug.demo.BugReloadableDecisionTableTest.testReuseKnowledgePackage(BugReloadableDecisionTableTest.java:53)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months