JBossDeveloper

Hi Darran

I also tried the Client SASL PLAIN Method  with Server Side Kerberos Method ....

But it doesn't work....

I'm getting this Exception on server side, after login modul successfully authenticated my user...

16:38:36,156 INFO  [stdout] (Remoting "ux2084" task-1) Pre-Authenticaton: find key for etype = 23

16:38:36,156 INFO  [stdout] (Remoting "ux2084" task-1) AS-REQ: Add PA_ENC_TIMESTAMP now

16:38:36,156 INFO  [stdout] (Remoting "ux2084" task-1) >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType

16:38:36,156 INFO  [stdout] (Remoting "ux2084" task-1) >>> KrbAsReq calling createMessage

16:38:36,157 INFO  [stdout] (Remoting "ux2084" task-1) >>> KrbAsReq in createMessage

16:38:36,157 INFO  [stdout] (Remoting "ux2084" task-1) >>> KrbKdcReq send: kdc=domain.com TCP:88, timeout=30000, number of retries =3, #bytes=253

16:38:36,158 INFO  [stdout] (Remoting "ux2084" task-1) >>>DEBUG: TCPClient reading 1594 bytes

16:38:36,158 INFO  [stdout] (Remoting "ux2084" task-1) >>> KrbKdcReq send: #bytes read=1594

16:38:36,158 INFO  [stdout] (Remoting "ux2084" task-1) >>> KrbKdcReq send: #bytes read=1594

16:38:36,158 INFO  [stdout] (Remoting "ux2084" task-1) >>> KdcAccessibility: remove domain.com:88

16:38:36,159 INFO  [stdout] (Remoting "ux2084" task-1) >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType

16:38:36,159 INFO  [stdout] (Remoting "ux2084" task-1) >>> KrbAsRep cons in KrbAsReq.getReply HTTP/server.domain.com

16:38:36,159 INFO  [stdout] (Remoting "ux2084" task-1) principal is HTTP/server.domain.com@DOMAIN.COM

16:38:36,159 INFO  [stdout] (Remoting "ux2084" task-1) EncryptionKey: keyType=23 keyBytes (hex dump)=0000: A9 D6 73 97 F2 86 F4 B0   B7 0D 45 D6 CB DB ED 9C  ..s.......E.....

16:38:36,159 INFO  [stdout] (Remoting "ux2084" task-1)

16:38:36,160 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (Remoting "ux2084" task-1) Begin isValid, principal:rrad, cache entry: null

16:38:36,160 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (Remoting "ux2084" task-1) defaultLogin, principal=rrad

16:38:36,160 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] (Remoting "ux2084" task-1) Begin getAppConfigurationEntry(other), size=3

16:38:36,160 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] (Remoting "ux2084" task-1) End getAppConfigurationEntry(other), authInfo=AppConfigurationEntry[]:

[0]

LoginModule Class: com.sun.security.auth.module.Krb5LoginModule

ControlFlag: LoginModuleControlFlag: required

Options:

name=useKeyTab, value=true

name=storeKey, value=true

name=principal, value=HTTP/server.domain.com@DOMAIN.COM

name=keyTab, value=/etc/krb5.keytab

name=debug, value=true

name=doNotPrompt, value=true

[1]

LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule

ControlFlag: LoginModuleControlFlag: optional

Options:

name=password-stacking, value=useFirstPass

[2]

LoginModule Class: org.jboss.as.security.RealmDirectLoginModule

ControlFlag: LoginModuleControlFlag: optional

Options:

name=password-stacking, value=useFirstPass

 

16:38:36,175 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (Remoting "ux2084" task-1) Login failure: javax.security.auth.login.LoginException: java.lang.StackOverflowError

        at java.lang.System.getProperty(System.java:647)

        at java.lang.Boolean.getBoolean(Boolean.java:221)

        at sun.security.action.GetBooleanAction.run(GetBooleanAction.java:53)

        at sun.security.action.GetBooleanAction.run(GetBooleanAction.java:32)

        at java.security.AccessController.doPrivileged(Native Method)

        at sun.security.jgss.krb5.Krb5Util.<clinit>(Krb5Util.java:30)

        at com.sun.security.auth.module.Krb5LoginModule.commit(Krb5LoginModule.java:959)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)

        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)

        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)

        at java.security.AccessController.doPrivileged(Native Method)

        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)

        at javax.security.auth.login.LoginContext.login(LoginContext.java:580)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)

        at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:354)

        at org.jboss.as.security.service.SimpleSecurityManager.push(SimpleSecurityManager.java:324)

        at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:157)

        at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:164)

        at org.jboss.as.security.RealmDirectLoginModule.handle(RealmDirectLoginModule.java:168)

        at org.jboss.as.security.RealmDirectLoginModule.validatePassword(RealmDirectLoginModule.java:199)

        at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:290)

        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)

        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)

        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)

        at java.security.AccessController.doPrivileged(Native Method)

        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)

        at javax.security.auth.login.LoginContext.login(LoginContext.java:579)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)

        at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:354)

        at org.jboss.as.security.service.SimpleSecurityManager.push(SimpleSecurityManager.java:324)

        at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:157)

        at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:164)

        at org.jboss.as.security.RealmDirectLoginModule.handle(RealmDirectLoginModule.java:168)

        at org.jboss.as.security.RealmDirectLoginModule.validatePassword(RealmDirectLoginModule.java:199)

        at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:290)

        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)

        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)

        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)

        at java.security.AccessController.doPrivileged(Native Method)

        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)

        at javax.security.auth.login.LoginContext.login(LoginContext.java:579)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371)

        at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160)

I'm not shure why... here is the security domain config from standalone.xml:

<subsystem xmlns="urn:jboss:domain:security:1.2">

            <security-domains>

                <security-domain name="other" cache-type="default">

                    <authentication>

                         <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">

                              <module-option name="debug" value="true"/>

                              <module-option name="principal" value="HTTP/server.domain.com@domain.com"/>

                              <module-option name="storeKey" value="true"/>

                              <module-option name="useKeyTab" value="true"/>

                              <module-option name="doNotPrompt" value="true"/>

                              <module-option name="keyTab" value="/etc/krb5.keytab"/>

                         </login-module>

                        <login-module code="Remoting" flag="optional">

                            <module-option name="password-stacking" value="useFirstPass"/>

                        </login-module>

                        <login-module code="RealmDirect" flag="optional">

                            <module-option name="password-stacking" value="useFirstPass"/>

                        </login-module>

                    </authentication>

 

                    <mapping>

                        <mapping-module code="org.jboss.security.mapping.providers.role.PropertiesRolesMappingProvider" type="role">

                             <module-option name="rolesProperties" value="file:${jboss.server.config.dir}/sl-user-roles.properties"/>

                        </mapping-module>

                     </mapping>

                </security-domain>

                <security-domain name="jboss-web-policy" cache-type="default">

                    <authorization>

                        <policy-module code="Delegating" flag="required"/>

                    </authorization>

                </security-domain>

                <security-domain name="jboss-ejb-policy" cache-type="default">

                    <authorization>

                        <policy-module code="Delegating" flag="required"/>

                    </authorization>

                </security-domain>

            </security-domains>

        </subsystem>

Mabe you can test it or you have allready a solution

Can it be, that jboss security expect something to be set by login modul... which is set by jboss login modul and is not set by simple jdk jaas login modul.. which trigger then looping login until stack overflow?

From Stack trace :

org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin()

calls somwhere in call chain org.jboss.as.security.RealmDirectLoginModule.validatePassword(RealmDirectLoginModule.java:199)

which calls org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin() and it loops forever....

Yeah that StackOverflow is an invalid configuration - you can't delegate from a realm to a jass definition that then delegates back to the same realm as you will end up in a loop like this.

Oh.... I see  ... login-module code="RealmDirect"  in security Domain make the loop back to security realm...

Ok, I remove the login-module code="RealmDirect" from Domain and it works now perfectly!

So at least Server Side GSSAPI with SASL PLAIN on Client ( I now... not very secure ) works!

    <login-module code="RealmDirect" flag="optional">

                            <module-option name="password-stacking" value="useFirstPass"/>

     </login-module>

17:44:38,566 INFO  [stdout] (EJB default - 1) >>>DEBUG: TCPClient reading 1594 bytes

17:44:38,566 INFO  [stdout] (EJB default - 1) >>> KrbKdcReq send: #bytes read=1594

17:44:38,566 INFO  [stdout] (EJB default - 1) >>> KrbKdcReq send: #bytes read=1594

17:44:38,567 INFO  [stdout] (EJB default - 1) >>> KdcAccessibility: remove domain.com:88

17:44:38,567 INFO  [stdout] (EJB default - 1) >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType

17:44:38,569 INFO  [stdout] (EJB default - 1) >>> KrbAsRep cons in KrbAsReq.getReply HTTP/server.domain.com

17:44:38,569 INFO  [stdout] (EJB default - 1) principal is HTTP/server.domain.com@domain.com

17:44:38,569 INFO  [stdout] (EJB default - 1) EncryptionKey: keyType=23 keyBytes (hex dump)=0000: A9 D6 73 97 F2 86 F4 B0   B7 0D 45 D6 CB DB ED 9C  ..s.......E.....

17:44:38,569 INFO  [stdout] (EJB default - 1)

17:44:38,570 INFO  [stdout] (EJB default - 1) Added server's keyKerberos Principal HTTP/server.domain.com@domain.comKey Version 3key EncryptionKey: keyType=23 keyBytes (hex dump)=

17:44:38,571 INFO  [stdout] (EJB default - 1) 0000: A9 D6 73 97 F2 86 F4 B0   B7 0D 45 D6 CB DB ED 9C  ..s.......E.....

17:44:38,571 INFO  [stdout] (EJB default - 1)

17:44:38,571 INFO  [stdout] (EJB default - 1)

17:44:38,571 INFO  [stdout] (EJB default - 1)           [Krb5LoginModule] added Krb5Principal  HTTP/server.domain.com@domain.com to Subject

17:44:38,571 INFO  [stdout] (EJB default - 1) Commit Succeeded

17:44:38,571 INFO  [stdout] (EJB default - 1)

17:44:38,572 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (EJB default - 1) defaultLogin, lc=javax.security.auth.login.LoginContext@169a85d, subject=Subject(28091822).principals=javax.security.auth.kerberos.KerberosPrincipal@14884594(HTTP/server.domain.com@domain.com)

17:44:38,575 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (EJB default - 1) updateCache, inputSubject=Subject(28091822).principals=javax.security.auth.kerberos.KerberosPrincipal@14884594(HTTP/server.domain.com@domain.com), cacheSubject=Subject(28410353).principals=javax.security.auth.kerberos.KerberosPrincipal@14884594(HTTP/server.domain.com@domain.com)

17:44:38,576 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (EJB default - 1) Inserted cache info: org.jboss.security.authentication.JBossCachedAuthenticationManager$DomainInfo@c9f71b

17:44:38,576 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (EJB default - 1) End isValid, true

17:44:38,588 INFO  [stdout] (EJB default - 1) SecurityTestService: 'permittAllMethod' successfully called! Input was: remote call TestServiceItf.permittAllMethod()

17:44:38,590 INFO  [stdout] (EJB default - 1) Principal: HTTP/server.domain.com@domain.com

Thanks for the hint :-)

...this modul is by default in standalone.xml

you now why for which case this is needed?

The reason that login module is within the default configuration is so that access to the properties files definitions can be managed with the realms - secured resources such as JBoss Web deployments can then call the security domain directly which will delegate back to the realm.  In this case you are no longer defining your repository of users within the realm as you are using a login module to authenticate them so the removal of that login module is correct.

ok. jboss security with picketbox is really great!

Hi Darran,

This subject is rather old but we are currently trying to configure an helloworld remote ejb application (not web) with a GSSAPI/kerberos authentication on linux. We use JBoss EAP 6.2.

We've been stuck for weeks trying that. Is it really possible with this version ? From what I read in different posts, it's not clear.

Our configuration is close to npabst's one (first message of the thread). But we get the following error message on the server :

GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos credentails)

at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Unknown Source)

I guess that the server cannot find the service ticket, can it ? But on the client side, we can see that it is requested to the TGS and received from the TGS.

Any help would be greatly appreciated

Tristan

Hi Darran,

I wonder if GSSAPI/Kerberos auth via remoting connections is now possible in Wildfly 8.1.0.Final? It is something to be done in this topic or WildFly has already working solution?