glassfish
  1. glassfish
  2. GLASSFISH-18993

RealmAdapter.createFailOveredPrincipal results in excepcion when LdapRealm is used

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2_b23
    • Fix Version/s: future release
    • Component/s: security
    • Labels:
      None
    • Environment:

      Linux magneto 3.2.0-3-amd64 x86_64 GNU/Linux (debian wheezy)

      Description

      I posted this question in the forums but as nobody said nothing I have decided to open a bug. I am trying to implement a couchbase session manager for glassfish (https://github.com/rickyepoderi/couchbase-manager) and trying to maintain the Security Contenxt in an application that uses JavaEE Security I found an issue.

      Currently my application saves in the external repo only the username of the logged user (I checked implementation of the ReplicationStore http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/web/web-ha/src/main/java/org/glassfish/web/ha/session/management/ReplicationStore.java). This way when the client accesses another server, the manager retrieves the session from the repo, it gets the username and performs a silently login using RealmAdapter.createFailOveredPrincipal to get all the principals (http://java.net/projects/glassfish/sources/svn/content/trunk/main/appserver/security/webintegration/src/main/java/com/sun/web/security/RealmAdapter.java). This works perfectly with FileRealm but if I use a LdapRealm it produces the following exception:

      [#|2012-07-28T16:21:28.190+0200|WARNING|glassfish3.1.2|javax.enterprise.system.core.security.com.sun.enterprise.security.auth.realm|_ThreadID=24;_ThreadName=Thread-2;|SEC1114: Exception in LdapRealm when trying to locate groups for user.
      java.io.IOException: Incorrect AVA format
      at sun.security.x509.AVA.readChar(AVA.java:564)
      at sun.security.x509.AVA.(AVA.java:185)
      at sun.security.x509.AVA.(AVA.java:145)
      at sun.security.x509.RDN.(RDN.java:151)
      at sun.security.x509.X500Name.parseDN(X500Name.java:935)
      at sun.security.x509.X500Name.(X500Name.java:165)
      at sun.security.x509.X500Name.(X500Name.java:152)
      at com.sun.enterprise.security.auth.realm.ldap.LDAPRealm.getGroups(LDAPRealm.java:368)
      at com.sun.enterprise.security.auth.realm.ldap.LDAPRealm.getGroupNames(LDAPRealm.java:416)
      at com.sun.enterprise.security.auth.login.LoginContextDriver.loginPrincipal(LoginContextDriver.java:294)
      at com.sun.web.security.RealmAdapter.loginForRunAs(RealmAdapter.java:659)
      at com.sun.web.security.RealmAdapter.createFailOveredPrincipal(RealmAdapter.java:714)
      at es.rickyepoderi.couchbasemanager.session.CouchbaseWrapperSession.fill(CouchbaseWrapperSession.java:363)
      at es.rickyepoderi.couchbasemanager.session.CouchbaseManager.doSessionLoad(CouchbaseManager.java:766)
      at es.rickyepoderi.couchbasemanager.session.CouchbaseManager.findSession(CouchbaseManager.java:488)
      at es.rickyepoderi.couchbasemanager.session.CouchbaseManager.findSession(CouchbaseManager.java:540)
      at org.apache.catalina.connector.Request.doGetSession(Request.java:2860)
      at org.apache.catalina.connector.Request.getSessionInternal(Request.java:2777)
      at org.apache.catalina.connector.Request.lockSession(Request.java:4154)
      at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:312)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231)
      at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317)
      at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
      at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
      at com.sun.grizzly.http.ajp.AjpProcessorTask.invokeAdapter(AjpProcessorTask.java:125)
      at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
      at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
      at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
      at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
      at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
      at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
      at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
      at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
      at java.lang.Thread.run(Thread.java:679)

      #]

      After checking the LdapRealm (http://java.net/projects/glassfish/sources/svn/content/tags/3.1.2/security/core/src/main/java/com/sun/enterprise/security/auth/realm/ldap/LDAPRealm.java) implementation is easy to understand that the problem is that the getGroups method in that realm expects a DN (LDAP Distinguished Name) and not the plain username.

      Please, I just want to know if it can be considered as a bug in the LdapRealm implementation or if I need to change the way I implement JavaEE security retrieval (as I said I posted this question in the forums but nobody answered me, I also tried to be included in the dev list but again no answer).

      Thanks!

        Activity

        Hide
        mbj_whitestein added a comment -

        We had the similar issue. The problem in our case was that we've used annotation RunAs with "processAgent" as principal. Workaround for us was to change sun-application.xml in a following way:

        <security-role-mapping>
        <role-name>processAgent</role-name>
        <principal-name>CN=processAgent,CN=Users,DC=company,DC=localdomain</principal-name>
        </security-role-mapping>

        In other words, we've changed principal-name from simple name (processAgent) to DN - this DN doesn't even need to exist, it's just to satisfy glassfish.

        Show
        mbj_whitestein added a comment - We had the similar issue. The problem in our case was that we've used annotation RunAs with "processAgent" as principal. Workaround for us was to change sun-application.xml in a following way: <security-role-mapping> <role-name>processAgent</role-name> <principal-name>CN=processAgent,CN=Users,DC=company,DC=localdomain</principal-name> </security-role-mapping> In other words, we've changed principal-name from simple name (processAgent) to DN - this DN doesn't even need to exist, it's just to satisfy glassfish.
        Hide
        rsoika added a comment -

        I have the same problem using Glassfish 3 togehter with an Microsoft Active Directory

        Show
        rsoika added a comment - I have the same problem using Glassfish 3 togehter with an Microsoft Active Directory

          People

          • Assignee:
            JeffTancill
            Reporter:
            rickyepoderi
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: