Bug 961656 - Support LDAP users for authenticating in the rest-api
Support LDAP users for authenticating in the rest-api
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: REST (Show other bugs)
JON 3.2
Unspecified Unspecified
urgent Severity urgent
: GA
: JON 3.2.0
Assigned To: Heiko W. Rupp
:
Depends On:
Blocks: 962438
  Show dependency treegraph
 
Reported: 2013-05-10 03:48 EDT by Heiko W. Rupp
Modified: 2014-01-02 15:37 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 962438 (view as bug list)
Environment:
Last Closed: 2014-01-02 15:37:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch testing option 2 fix. (8.12 KB, patch)
2013-05-14 07:50 EDT, Simeon Pinder
no flags Details | Diff

  None (edit)
Description Heiko W. Rupp 2013-05-10 03:48:25 EDT
The authentication in the REST api currently only supports local users, but no LDAP users.

We need to fix that.
Comment 1 Heiko W. Rupp 2013-05-13 05:37:30 EDT
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)
Comment 2 Heiko W. Rupp 2013-05-13 07:07:57 EDT
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:
Comment 3 Simeon Pinder 2013-05-14 07:50:13 EDT
Created attachment 747658 [details]
patch testing option 2 fix.
Comment 4 Simeon Pinder 2013-05-14 07:50:46 EDT
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?
Comment 5 Heiko W. Rupp 2013-05-14 12:20:07 EDT
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
Comment 6 Heiko W. Rupp 2013-05-16 15:58:31 EDT
master ba97ade9666a
Comment 8 Libor Zoubek 2013-06-04 04:46:50 EDT
Login as LDAP user fails under certain conditions, I've opened Bug 970517 for it.
Comment 9 Mike Foley 2013-08-01 09:22:13 EDT
based on comment #8, i am setting this back to dev.

Note You need to log in before you can comment on or make changes to this bug.