[JBoss JIRA] (ELY-1475) Empty username for FormAuthenticationMechanism causes IllegalArgumentException
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1475:
----------------------------------
Fix Version/s: 1.7.0.CR4
(was: 1.7.0.CR3)
> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
> Key: ELY-1475
> URL: https://issues.jboss.org/browse/ELY-1475
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.2.0.Beta11
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Priority: Major
> Fix For: 1.7.0.CR4
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1687?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1687:
----------------------------------
Fix Version/s: 1.7.0.CR4
(was: 1.7.0.CR3)
> Initial WildFly Elytron Performance Enhancments
> -----------------------------------------------
>
> Key: ELY-1687
> URL: https://issues.jboss.org/browse/ELY-1687
> Project: WildFly Elytron
> Issue Type: Task
> Affects Versions: 1.7.0.CR2
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.7.0.CR4
>
> Attachments: BASIC_Auth_Load.jmx, Flight.tgz
>
>
> Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues.
> After that we will perform the initial metric test again and close the issue.
> A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test.
> The first test is to test HTTP Basic authentication backed by WildFly Elytron.
> * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate.
> Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes.
> h2. Initial Issues
> h3. WildFlyElytronProvider Locking
> Total block time 8.393s via calls to java.security.Provider.getServices();
> Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance.
> h3. Memory 2.42G of char[]
> e.g.
> {noformat}
> void java.nio.HeapCharBuffer.<init>(int, int) 13037
> CharBuffer java.nio.CharBuffer.allocate(int) 9148
> CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148
> CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148
> {noformat}
> Is there any option to re-use these as they can be cleared instead of leaving to GC.
> HeapByteBuffer and HeapCharBuffer are also quite prominent.
> h3. Memory 1.78G of Callback[]
> Using the CallbackHandler API the use of the array is inevitable.
> * Could we extend the API to avoid the array?
> * Could we re-use the array? Could consider null termination.
> {noformat}
> boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222
> void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222
> {noformat}
> h3. Memory 1.41G of HttpAuthenticator$Builder
> {noformat}
> HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699
> boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699
> {noformat}
> Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use?
> h3. Memory 1.3G of SecurityContextImpl
> {noformat}
> SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247
> SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673
> {noformat}
> Also instances of HttpAuthenticator
> {noformat}
> HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624
> {noformat}
> And instances of HttpAuthenticator$AuthenticationExchange.
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423
> {noformat}
> As with HttpAuthenticator$Builder is there any way to consider re-use?
> h3. Memory 1.21G of java.util.ArrayList
> {noformat}
> boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911
> {noformat}
> Can check the use and see if an alternative is possible.
> _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._
> _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._
> https://issues.jboss.org/browse/ELYWEB-26
> h3. Memory ServerAuthenticationContext States
> Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states.
> Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance?
> h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[]
> {noformat}
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091
> FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091
> {noformat}
> This test did not use forms at all, is this something that can be delayed until we know it is needed?
> _It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._
> https://issues.jboss.org/browse/ELYWEB-27
> h3. Memory SecurityIdentity
> As an immutable object we can end up with intermediate throw away instances, can we optimise create once?
> {noformat}
> SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454
> ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454
> {noformat}
> h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator
> These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages.
> Could a static Base64 conversion clean up a lot of this?
> h1. Done
> h3. Method Profiling - new HttpString
> A lot of time spend creating new HttpString (Package is no3 in the top list)
> {noformat}
> void io.undertow.util.HttpString.<init>(String) 4
> void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4
> {noformat}
> Could we re-use the HttpString for common header types?
> Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1682:
----------------------------------
Fix Version/s: 1.7.0.CR4
(was: 1.7.0.CR3)
> Fallback to another SASL client mechanism when SASL client initialisation fails
> -------------------------------------------------------------------------------
>
> Key: ELY-1682
> URL: https://issues.jboss.org/browse/ELY-1682
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR4
>
> Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
>
>
> {code:title=HipChat conversation}
> Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential.
> But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok.
> I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
> Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
> Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case).
> In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
> Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting
> though for that one as that is where that loop happens but start with an ELY issue
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (ELY-1680) IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1680?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1680:
----------------------------------
Fix Version/s: 1.7.0.CR4
(was: 1.7.0.CR3)
> IBM, failing KeyStoreSuiteChild.testGetCertificateChainBinary
> -------------------------------------------------------------
>
> Key: ELY-1680
> URL: https://issues.jboss.org/browse/ELY-1680
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Major
> Fix For: 1.7.0.CR4
>
> Attachments: ldap-keystore-gen.sh
>
>
> {code}
> [ERROR] testGetCertificateChainBinary(org.wildfly.security.ldap.KeyStoreSuiteChild) Time elapsed: 0.057 s <<< FAILURE!
> org.junit.ComparisonFailure: expected:<CN=[firefly_binary], OU=Elytron, O=Elyt...> but was:<CN=[localhost], OU=Elytron, O=Elyt...>
> at org.wildfly.security.ldap.KeyStoreSuiteChild.testGetCertificateChainBinary(KeyStoreSuiteChild.java:136)
> at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218)
> {code}
> If I switch order of certificates in chain, then test passes.
> {code}
> diff --git a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> index d8095867a..cda635beb 100644
> --- a/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> +++ b/src/test/java/org/wildfly/security/ldap/KeyStoreSuiteChild.java
> @@ -133,8 +133,8 @@ public class KeyStoreSuiteChild {
> Certificate[] chain = keyStore.getCertificateChain("firefly_binary");
> Assert.assertNotNull(chain);
> Assert.assertEquals(2, chain.length);
> - Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> - Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=firefly_binary, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[1]).getSubjectDN().toString());
> + Assert.assertEquals("CN=localhost, OU=Elytron, O=Elytron, L=Elytron, ST=Elytron, C=UK", ((X509Certificate)chain[0]).getSubjectDN().toString());
> }
> {code}
> -For some reason I want able to debug code with -Dmaven.surefire.debug (Breakpoint was never hit) to find out which calls switch the order.-
> It takes long (5min) for debugger to attach to code.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (ELY-1677) Elytron Bearer Token Authentication - Return a 401 on Invalid Token
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1677?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1677:
----------------------------------
Fix Version/s: 1.7.0.CR4
(was: 1.7.0.CR3)
> Elytron Bearer Token Authentication - Return a 401 on Invalid Token
> -------------------------------------------------------------------
>
> Key: ELY-1677
> URL: https://issues.jboss.org/browse/ELY-1677
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Authentication Mechanisms
> Affects Versions: 1.7.0.CR1
> Reporter: Edward Stathopoulos
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 1.7.0.CR4
>
>
> *Issue*
> Currently, Elytron will send back a 403 Response when an invalid bearer token is sent. For the built-in JWT validator (the token validation we are using), this [includes a few checks like signature, expiration time, audience and issuer|https://github.com/wildfly-security/wildfly-elytron/blob/1.7.0.CR1...].
> It seems that the current [BearerTokenAuthenticationMechanism|https://github.com/wildfly-security/wi...] does not differentiate between failed authentication and failed authorization, returning a 403 in both cases. This produces conflicting and erroneous results. Did I fail to authenticate (say, expired JWT) or did I authenticate but do not have access to the resource in question?
> This would also be closer in line with [RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage)|https://tools.ietf.org/html/rfc6750#section-3] which includes an example of an expired (invalid) token.
> {quote}
> And in response to a protected resource request with an
> authentication attempt using an expired access token:
> HTTP/1.1 401 Unauthorized
> WWW-Authenticate: Bearer realm="example",
> error="invalid_token",
> error_description="The access token expired"
> {quote}
> *Potential Solution*
> Perhaps this could be ameliorated by something akin to the following change in BearerTokenAuthenticationMechanism::evaluateRequest by differentiating between failure to authorize and failure to authenticate the token. Merely a quick, unvetted example as I haven't had enough time to dig in to the source.
> {code}
> if (verifyCallback.isVerified()) {
> AuthorizeCallback authorizeCallback = new AuthorizeCallback(null, null);
> handleCallback(authorizeCallback);
> if (authorizeCallback.isAuthorized()) {
> httpBearer.debugf("Token authentication successful.");
> handleCallback(new IdentityCredentialCallback(new BearerTokenCredential(tokenEvidence.getToken()), true));
> handleCallback(AuthenticationCompleteCallback.SUCCEEDED);
> request.authenticationComplete();
> return;
> }
> else{
> httpBearer.debugf("Token authorization failed message.");
> request.authenticationFailed("Some token unauthorized message", response -> response.setStatusCode(FORBIDDEN));
> return;
> }
> }
> httpBearer.debugf("Token authentication failed.");
> request.authenticationFailed("Invalid bearer token", response -> response.setStatusCode(UNAUTHORIZED));
> return;
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (ELY-1675) Merge roles from entry and entry attributes
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1675?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1675:
----------------------------------
Fix Version/s: 1.7.0.CR4
(was: 1.7.0.CR3)
> Merge roles from entry and entry attributes
> -------------------------------------------
>
> Key: ELY-1675
> URL: https://issues.jboss.org/browse/ELY-1675
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Priority: Critical
> Fix For: 1.7.0.CR4
>
>
> Double check Elytron ldap realm is capable doing this:
> Having ldap entries like this
> {code}
> dn: cn=jduke,ou=Roles,ou=example2,${dnSuffix}
> objectClass: top
> objectClass: organizationalRole
> description: cn=Echo,ou=Roles,ou=example2,${dnSuffix}
> description: cn=TheDuke,ou=Roles,ou=example2,${dnSuffix}
> cn: jduke
> {code}
> User will have roles jduke, Echo and TheDuke.
> This was possible with Picketbox with this configuration
> {code}
> EapSetupTask roleAttributesConfiguration =
> new LdapExtSecurityDomainBuilder(SECURITY_DOMAIN_NAME_PREFIX + DEP2)
> .prepareDefaultForLdapServer(ldapServer)
> .baseCtxDN("ou=People,ou=example2," + ldapServer.getDNSuffix())
> .rolesCtxDN("ou=Roles,ou=example2," + ldapServer.getDNSuffix())
> .referral("ignore")
> .roleFilter("(|(objectClass=referral)(cn={0}))")
> .roleAttributeID("description")
> .roleAttributeIsDN("true")
> .roleNameAttributeID("cn")
> .roleRecursion("0")
> .configure();
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (ELY-1668) LDAP searchScope=OBJECT_SCOPE Elytron alternative
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1668?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1668:
----------------------------------
Fix Version/s: 1.7.0.CR4
(was: 1.7.0.CR3)
> LDAP searchScope=OBJECT_SCOPE Elytron alternative
> -------------------------------------------------
>
> Key: ELY-1668
> URL: https://issues.jboss.org/browse/ELY-1668
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.6.1.Final
> Reporter: Martin Choma
> Priority: Critical
> Fix For: 1.7.0.CR4
>
>
> During comparing PicketBox an Elytron we came to one scenario which I am not sure if is covered by Elytron.
> "As a user I am able to authenticate and authorize into web application secured by LDAP (where the same is used for storing identities and roles) and roles are stored in tree structure and should be only referenced object." Author is Ondra Lukas which is not with us anymore so I tried to think about what could this be about? Based on context I came to conclusion this is about OBJECT_SCOPE value of property searchScope.
> Could you revise if same is possible with Elytron? But anyway I am not sure how that feature can be useful. But maybe there is some corner case it can be useful I am not aware of.
> {code}
> dn: ou=People,${dnSuffix}
> objectclass: top
> objectclass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,${dnSuffix}
> objectclass: top
> objectclass: person
> objectclass: inetOrgPerson
> uid: jduke
> cn: Java Duke
> sn: Duke
> userPassword: Password1
> dn: ou=RolesLevel1,${dnSuffix}
> objectclass: top
> objectclass: organizationalUnit
> ou: RolesLevel1
> dn: cn=RoleUnderLevel1,ou=RolesLevel1,${dnSuffix}
> objectclass: top
> objectclass: groupOfNames
> cn: RoleUnderLevel1
> member: uid=jduke,ou=People,${dnSuffix}
> description: the RoleUnderLevel1 group
> {code}
> [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months
[JBoss JIRA] (DROOLS-3149) [DMN Designer] Context top level data type
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3149?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3149:
----------------------------------------
[~jomarko] I could only replicate when the {{Context}} editor was in this _state_:
!DROOLS-3149.png|thumbnail!
Changing the "Decison-1" data-type did indeed lead to the "ContextEntry-1" properties being shown.
The fix I have submitted ensures when the editor is in the shown _state_ that editing the "Decision-1" does not show the "ContextEntry-1" properties.
At the moment we do not support _selecting_ headers (visually; i.e. no blue border around a header). When this is fixed (there is a JIRA assigned to [~danielezonca] I believe) we should be able to improve things. At the moment when the editor is in the shown state and "Decision-1" edited there is no _selection_.
> [DMN Designer] Context top level data type
> ------------------------------------------
>
> Key: DROOLS-3149
> URL: https://issues.jboss.org/browse/DROOLS-3149
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.14.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: DROOLS-3149.png
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 9 months