The authentication in the REST api currently only supports local users, but no LDAP users. We need to fix that.
The simplest way to support LDAP would be to switch to the "RHQUserSecurityDomain", which fails as RHQ is removing / re-adding the domain on each start. EAP sees this and complains that the removal would leave the rhq-rest.war in an illegal state (with a referenced but not provided security-domain) -- see below I currently see three possible options: 1) add the logic to add/remove LDAP support to the RHQRESTSecurityDomain 2) Fix the RHQUserSecurityDomain setup in the CustomJaasDeploymentService to not touch the security-domain on each restart and to only add/remove the LDAP module when requested (and perhaps change flags on the other modules. 3) Check if the remove/re-add can be done in Transaction (A EAP-composite operation), so that other services only see the end result. 11:26:28,758 INFO [org.rhq.enterprise.server.core.CustomJaasDeploymentService] (EJB default - 1) Security domain [RHQUserSecurityDomain] already exists, it will be replaced. 11:26:28,804 INFO [org.jboss.web] (ServerService Thread Pool -- 82) JBAS018224: Unregister web context: /rest 11:26:28,806 INFO [org.rhq.helpers.rtfilter.filter.RtFilter] (ServerService Thread Pool -- 82) -- Filter destroy: 0 requests processed (hashCode=226618607). 11:26:28,813 INFO [org.jboss.web] (ServerService Thread Pool -- 82) JBAS018210: Register web context: /rest 11:26:28,820 INFO [org.rhq.helpers.rtfilter.filter.RtFilter] (ServerService Thread Pool -- 82) Initialized response-time filter for webapp with context root 'rest'. 11:26:28,823 ERROR [org.rhq.enterprise.server.core.CustomJaasDeploymentService] (EJB default - 1) Error deploying JAAS login modules: java.lang.Exception: Error registering RHQ JAAS modules at org.rhq.enterprise.server.core.CustomJaasDeploymentService.registerJaasModules(CustomJaasDeploymentService.java:176) [rhq-enterprise-server-ejb3.jar:4.8.0-SNAPSHOT] at org.rhq.enterprise.server.core.CustomJaasDeploymentService.installJaasModules(CustomJaasDeploymentService.java:76) [rhq-enterprise-server-ejb3.jar:4.8.0-SNAPSHOT] Caused by: org.rhq.common.jbossas.client.controller.FailureException: Failed to remove security domain [RHQUserSecurityDomain]: JBAS014762: Removing services has lead to unsatisfied dependencies: Service jboss.security.security-domain.RHQUserSecurityDomain was depended upon by service jboss.web.deployment.default-host./rest.realm at org.rhq.common.jbossas.client.controller.SecurityDomainJBossASClient.removeSecurityDomain(SecurityDomainJBossASClient.java:256)
I think doing option 2) got just easier with the use of EAP6.1, as this now allows to individually address login modules: [standalone@localhost:6999 authentication=classic] ./login-module=org.rhq.enterprise.server.core.jaas. org.rhq.enterprise.server.core.jaas.JDBCLoginModule org.rhq.enterprise.server.core.jaas.JDBCPrincipalCheckLoginModule org.rhq.enterprise.server.core.jaas.LdapLoginModule [standalone@localhost:6999 authentication=classic] ./login-module=org.rhq.enterprise.server.core.jaas.LdapLoginModule: add read-attribute read-children-names read-children-resources read-children-types read-operation-description read-operation-names read-resource read-resource-description remove undefine-attribute whoami write-attribute [standalone@localhost:6999 authentication=classic] ./login-module=org.rhq.enterprise.server.core.jaas.LdapLoginModule:
Created attachment 747658 [details] patch testing option 2 fix.
This is the approach I was describing via irc. See patch. Basically we update the security domain without having to go through the management api and triggering the dependency update. I applied the patch and quickly retested LDAP authorization successfully. This is basically option 2 above without involving the management api. Heiko, does this give you the flexibility that you need?
Discussion from yesterday on #rhq [17:16:59] <mazz> all reconfiguration is done by the installer [17:17:55] <pilhuhn> so that custom jaas installer service on each start makes no sense anyway [17:18:13] <pilhuhn> k [17:23:52] <jshaughn> pilhuhn: I thought we had to do that to support our LDAP integration? [17:24:06] <pilhuhn> yes and no [17:24:17] <pilhuhn> we need to add/remove the ldap and another login module [17:24:26] <pilhuhn> but we do not need to do that on each start [17:24:35] <jshaughn> what if the config changed? [17:24:38] <pilhuhn> as the as saves that in standalone-full.xml over restarts [17:25:01] <pilhuhn> on change we modify [17:25:33] <jshaughn> As long as it's not possible for ldap to be turned on/off between starts I guess it's ok [17:25:37] <pilhuhn> Now there is an issue: complete removal + re-adding of the domain works with our security checking as we do not do container managed security for access control [17:25:38] <spinder> pilhuhn, jshaughn: So what we had in the previous version was that we didn't actually persist those changes to the file system. We just updated and redeployed the login module updates. So the persistence to the file sysem is actually new. [17:26:24] <pilhuhn> spinder exactly. Because as4 did not have that persistence. AS7 has that in the sense that *all* modifications through the api are reflected in standalone.xlm [17:26:28] <pilhuhn> xml even [17:26:32] <spinder> and seems to now have some side effect that we did not anticipate. If I understand pilhuhn's comments correctly. [17:28:19] <pilhuhn> see https://bugzilla.redhat.com/show_bug.cgi?id=961656#c1 [17:29:19] <spinder> pilhuhn, jshaughn: so let me see if I still have that branch hanging around .. because I did figure out how to update the security domain in memory as we had before. It should be identical to the most recent changes .. without the xml persistence. iirc. [17:29:32] <pilhuhn> (to continue my above sentence) remove+add does not work with container managed security which we do for the REST-api (don't worry, all the internal code still uses our Mange*foo stuff) , as upon remove, the container complains that there is a unsatisfied reference to a security domain [17:29:42] <pilhuhn> spinder no [17:30:16] <spinder> reading the comments now.. [17:30:19] <pilhuhn> what we need to do is to just add/remove the ldap and the other jdbc login module when the user reconfigures the system [17:31:27] <spinder> pilhuhn: everytime they reconfigure the system... i.e. system reload? Or do you mean every time we enable/disable the optional ldap modules? [17:31:48] <pilhuhn> basically the latter [17:32:06] <pilhuhn> or more precisely when they click the reconfigure button [17:32:21] <pilhuhn> (save in the system settings) as this is done right now. [17:32:32] <pilhuhn> But then the change is persisted and available after the server reboot [17:32:48] <pilhuhn> not doing that on every reboot also speeds up server start (a bit ) [17:42:00] <spinder> pilhuhn: could we add another placeholder security domain(not used) that always has the rest/SecurityDomain dependencies enabled regardless for the current JON configuration domain setup? The intent being to always keep those modules loaded regardless of whether or not we currently need the ldapLoginModule? It seems a bit heavy handed to unload modules dependencies that can be legitimately be enabled/disabled based on customer ne [17:42:00] <spinder> eds. [17:42:44] <spinder> i don't recall if that's possible or how granular the module dependencies are. [17:43:21] <spinder> s/modules loaded/dependencies loaded [17:43:33] <pilhuhn> We used to have a (working) security domain for REST, but this does not honor LDAP. [17:43:54] <pilhuhn> option 1) mimic the behavior (but correctly) of the other domain [17:44:05] <pilhuhn> option 2) fix the other domain and re-use this [17:44:22] <pilhuhn> I think 2 is better, as we only have to track 1 place [17:44:56] <pilhuhn> currently we not only load/unload a module, we remove/add a whole domain which is heavier [17:45:12] <pilhuhn> but then I probably did not understand what you aked [17:45:41] <pilhuhn> Unfortuately the modules have no enabled/disabled setting [17:45:49] <spinder> right. 2) does seem easier .. with less duplicated logic/functionality. [17:46:00] <pilhuhn> And usually they are only enabled once and then left as they are [17:52:19] <spinder> pilhuhn: so from the error it looks like re-writing the security domain state to XML signals some wider clean that changes actual dependencies and redeploys. I was thinking we could looking into creating a new Security domain that always had all the dependencies so that even with a redeploy the optional module dependencies were still needed by the 'new' security domain .. but this whole approach is still more complicated than opt [17:52:20] <spinder> ions 2) which would avoid signalling the whole redeploy change altogether and should still work for rest as well. Since it just changes the current security domain state for the container. I'm on board with option 2. And then of course a retest/re-certify. [17:52:42] <tsegismont> spinder, correct me if i'm wrong, what you meant is: why can't we configure the whole chain of security only once and have some code in the ldap module to check in the database if ldap is enabled/disable? right? cc pilhuhn [17:53:21] <pilhuhn> spinder we still need to rewrite when the ldap attributes change - which would also fail [17:53:36] <tsegismont> that would be a little less efficient (query the dabase to check if ldap is enabled) but far simpler to configure [17:54:18] <pilhuhn> I could also just drop container managed security from REST -- but then there is no basic / digest / .. auth sitting front of the api --> not an option [17:54:34] <pilhuhn> and what we do is not rewritign the chain. [17:54:40] <pilhuhn> We remove it and re-add it later [17:54:40] <spinder> pilhuhn: what I'm proposing is not ever serializing the specific security module state to the file system. But just updating it in memory as we did for eap 4.x. [17:55:07] <pilhuhn> spinder AS7 / EAP6 does not work that way afaik [17:55:26] <spinder> pilhuhn: I had it almost working that way .. Just a few tweaks. [17:55:31] <pilhuhn> you can't say "make that change of your system state, but do not persist it" [17:55:42] pilhuhn will assign that BZ to spinder [17:55:44] <pilhuhn> :) [17:55:47] <spinder> lol! [17:56:02] spinder tries to pull his foot out of his mouth... lol [17:57:38] <pilhuhn> spinder the above fails because we remove the whole security domain [17:57:46] <spinder> pilhuhn, tsegismont: basically the approach was to .. on ldap module change, we would generate the new 'state of the security' domain and then tell the EAP container to use this new state. [17:57:54] <pilhuhn> which yields an error, as the rest-module has a dependency [17:58:24] <pilhuhn> So what we need to do it not to throw it away and re-create it [17:58:28] <pilhuhn> but just modify it [17:58:48] <jshaughn> pilhuhn: I didn't read the whole thing above, but option #2 from the BZ seems doable, right? [17:58:48] <pilhuhn> by adding/removing the login modules relevant to ldap [17:58:55] <pilhuhn> jshaughn yes [17:59:00] <jshaughn> leave the sec domain, just update the login modules [17:59:04] <spinder> correct. [17:59:08] <jshaughn> sounds reasonable [17:59:26] <spinder> let me finish my compass and then try to find that branch. [17:59:43] <jshaughn> if you do that then migrate RESt to the RHQ sec domain and blow away the REST sec domain [17:59:56] <pilhuhn> There is that little complication that the security domain is created in StartupBean for the first time, so I need to take this into account. But this is no biggie [18:00:05] <pilhuhn> jshaughn That is the idea [18:00:10] <jshaughn> ok, +1 [18:00:31] <spinder> +1. if it still works in eap 6.1, I think it's what we want. [18:00:51] <pilhuhn> Only have 1 domain - and if we introduce a FooBarModule in the future that asks for the pin from the Gemalto Tokens, we only have 1 place to modify [18:01:24] <pilhuhn> spinder EAP makes it easier -- as we do no longer deal with an array of modules, but can add/remove them ndividually [18:01:41] <jshaughn> I probably just dropped the whole domain for simplicity [18:01:44] <jshaughn> I don't remember [18:01:56] <pilhuhn> jshaughn I think that is how it was in as4 [18:02:05] <jshaughn> pilhuhn: just make sure the order of login modules is correct, that is important [18:02:44] <pilhuhn> and it works with coregui, as there is no dependency from a deployment descriptor. Now with rest there is the dependency from rhq-rest.war/jboss-web.xml to the domain
master ba97ade9666a
See also http://pilhuhn.blogspot.com/2013/05/creating-delegating-login-module-for.html
Login as LDAP user fails under certain conditions, I've opened Bug 970517 for it.
based on comment #8, i am setting this back to dev.