[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)
by Tom Fonteyne (JIRA)
[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ]
Tom Fonteyne updated WFLY-3418:
-------------------------------
Summary: deployed applications are not distributed to host controller(s) (was: deployed applications are not distrubuted to host controller(s))
> deployed applications are not distributed to host controller(s)
> ---------------------------------------------------------------
>
> Key: WFLY-3418
> URL: https://issues.jboss.org/browse/WFLY-3418
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.CR2
> Environment: Wildfly 8.1.0 CR5 domain mode
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
>
> when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (WFLY-3418) deployed applications are not distrubuted to host controller(s)
by Tom Fonteyne (JIRA)
Tom Fonteyne created WFLY-3418:
----------------------------------
Summary: deployed applications are not distrubuted to host controller(s)
Key: WFLY-3418
URL: https://issues.jboss.org/browse/WFLY-3418
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.1.0.CR2
Environment: Wildfly 8.1.0 CR5 domain mode
Reporter: Tom Fonteyne
Assignee: Brian Stansberry
when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder)
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (WFLY-3072) Support Referrals for security realms using LDAP for authentication or group loading.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3072:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1066488|https://bugzilla.redhat.com/show_bug.cgi?id=1066488] from ON_QA to VERIFIED
> Support Referrals for security realms using LDAP for authentication or group loading.
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3072
> URL: https://issues.jboss.org/browse/WFLY-3072
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.1.0.CR2, 8.1.0.Final
>
>
> I see the following scenarios to cover for this: -
> - Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct.
> Group loading then has a couple of issues, firstly where the user was a referral.
> The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both.
> Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there.
> And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection.
> The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading.
> * Connection Settings *
> We are going to need to support two different modes in relation to the 'java.naming.referral' property, follow and throw.
> - *follow* - In this mode when the InitialDirContext encounters a referral during a search it will automatically follow it, this means automatically connecting to the server in the URL. This is fine if the remaining connection settings are valid for the alternative server e.g. same bindDN and credential. We however need to take the following into account for subsequent operations such as password validation or further queries.
> - *throw* - When a referral is encountered and exception will be thrown instead, this mode should make it easier to have some more advanced referral handling logic that allows us control of which connection we subsequently use, e.g. we could not use a completely different host name to the one in the referral or use a different bind DN / credential pair.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (SASL-49) Custom Property to Prefer JDK Mechanisms
by Darran Lofthouse (JIRA)
Darran Lofthouse created SASL-49:
------------------------------------
Summary: Custom Property to Prefer JDK Mechanisms
Key: SASL-49
URL: https://issues.jboss.org/browse/SASL-49
Project: JBoss SASL Provider
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 2.0.0.Alpha1
This is primarily for testing although it could be used for other purposes, a new custom property should be added to JBoss SASL which will cause mechanisms that duplicate JDK supplied mechanisms to avoid being used themselves.
i.e. Even though JBoss SASL could supply an implementation for that mechanisms it will let the JDK supplied version win through.
For testing this will enable interoperability testing between our mechanisms and the JDK mechanisms, for end users they could use JBoss SASL for the new mechanisms we supply whilst still using the JDK for the mechanisms it supplied.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (WFLY-3416) NPE in Undertow Extension if login module doesn't set Principal
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3416?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-3416:
----------------------------------------
I will take this but the best you are going to get is an error message saying there is no Principal and the authentication attempt will be rejected.
The JAAS authentication if successful must add a Principal to the Subject.
> NPE in Undertow Extension if login module doesn't set Principal
> ---------------------------------------------------------------
>
> Key: WFLY-3416
> URL: https://issues.jboss.org/browse/WFLY-3416
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
>
> NPE is thrown during authentication if a LoginModule doesn't set any principal to the Subject.
> The problem comes from {{org.wildfly.extension.undertow.security.AccountImpl}} constructor call {{principal.getName()}}.
> {code}
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.AccountImpl.<init>(AccountImpl.java:61)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:123)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months
[JBoss JIRA] (WFLY-3416) NPE in Undertow Extension if login module doesn't set Principal
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3416?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-3416:
--------------------------------------
Assignee: Darran Lofthouse (was: Stuart Douglas)
> NPE in Undertow Extension if login module doesn't set Principal
> ---------------------------------------------------------------
>
> Key: WFLY-3416
> URL: https://issues.jboss.org/browse/WFLY-3416
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
>
> NPE is thrown during authentication if a LoginModule doesn't set any principal to the Subject.
> The problem comes from {{org.wildfly.extension.undertow.security.AccountImpl}} constructor call {{principal.getName()}}.
> {code}
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.security.AccountImpl.<init>(AccountImpl.java:61)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:123)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 11 months