Archive for March, 2013

LDAP authentication to HTTP Security Realm in JBoss EAP 6

So, you want to tie your jboss EAP 6 management interface into LDAP? Here’s how. This is for EAP 6 in Domain mode tying to an OpenLDAP server, but it should work for Standalone mode as well (I guess, I have no idea for sure).

Open up your jboss-eap/domain/configuration/host.xml and

  1. Add a new security realm:
    <security-realm name="LDAPRealm">
        <authentication>
            <ldap connection="ldap_connection" base-dn="ou=users,ou=people,dc=example,dc=com">
                <username-filter attribute="uid"/>
            </ldap>
        </authentication>
    </security-realm>
  2. In the same <management> block as <security-realms>, add
    <outbound-connections>
        <ldap name="ldap_connection" url="ldap://ldap.example.com" search-dn="cn=search,dc=example,dc=com" search-credential="secret"/>
    </outbound-connections>
  3. and in your management-interfaces, change the realm from ManagementRealm to LDAPRealm:
    <management-interfaces>
        <native-interface security-realm="LDAPRealm">
            <socket interface="management" port="${jboss.management.native.port:9999}"/>
        </native-interface>
        <http-interface security-realm="LDAPRealm">
            <socket interface="management" port="${jboss.management.http.port:9990}"/>
        </http-interface>
    </management-interfaces>

and restart EAP. Some caveats:

  1. JBoss is derpy and does not provide a way to anonymously bind for authentication, meaning the search-dn and search-credential are REQUIRED and you need to set up an inetOrgPerson or something to authenticate. It chokes if you leave either or both fields blank.
  2. This replaces the ManagementRealm that was previously used but does not remove it. If you lock yourself out, you can just revert step 3 to go back to using your hard-coded users.
  3. Note the lack of TLS being mentioned. Does that mean it’s plaintext? it didn’t complain that my cert was self signed, so that’s entirely likely. Perhaps you can use a ldaps:// url and use the older ssl method if you have it set up.  Very poor form in either case.

Let me know if this was any help.

Quick note on Mod_cluster, JBoss EAP and static content

While trying to configure mod_cluster for a new setup, I ran into a gotcha that got me good- first time I’ve ever seen apache httpd have an out of memory error in my 13 years of using it. The default behavior of mod cluster is to dynamically set up the basic context roots it receives from JBoss -i.e. foo.war has a context of /foo and mod_cluster will forward it without much explicit configuration on the httpd side.

Suppose you want static content at foo/images/ to be served by httpd? The docs are very clear that you can do that with ProxyPassMatch, but what it isn’t clear on is that adding it removed the default context configuration, leaving you to explicitly state it. Not only that, but it has to come AFTER the ProxyPassMatch statements. Here’s what a full example should look like.

ProxyPassMatch ^(/foo/css/.*)$ !
ProxyPassMatch ^(/foo/docs/.*)$ !
ProxyPassMatch ^(/foo/fonts/.*)$ !
ProxyPassMatch ^(/foo/htc/.*)$ !
ProxyPassMatch ^(/foo/html/.*)$ !
ProxyPassMatch ^(/foo/images/.*)$ !
ProxyPassMatch ^(/foo/js/.*)$ !
ProxyPass /foo balancer://myclustername/foo

 

Note that this is sort of backwards behavior from mod_jk and jkunmount. Hopefully this will help someone else. Leave a note if it does.

 

 

Hey, what’s that? Part 10: The Magical

So what else can our locationGenerator describe? How about a magical disturbance. This could be a number of things, from portals to fog to odd smells.

During your travels, you stumble across a magical disturbance. You [see/feel/taste/sense/smell/hear] something [strange/unique/powerful]. Ahead of you there is a [colorless/invisible/colorful/red] [portal/cloud/shadow]  [floating overhead/ hovering over the ground]. The disturbance fills you with feelings of [uneasiness/joy/revulsion], and yet you find yourself [attracted/repelled] by it.

Go to Top