Admin locked out of OxAuth

By: Ronald R. user 03 May 2019 at 7:21 p.m. CDT

8 Responses
Ronald R. gravatar
I've just setup a new Gluu server and enabled super-gluu as authentication method for OxAuth. I was hoping I would be able to enroll my device while logged in but unfortunately that does not seem possible. I've then proceeded to log out and log in again as to start the enrollment process. Unfortunately after scanning the QR code I receive the following error message on Android: ``` Failed to get FIDO U2F metadata ``` in oxauth.log it says the following: ``` 2019-05-04 00:14:40,639 INFO [qtp804611486-15] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:262) - Authentication success for Client: '@!0B6C.CFA2.B551.6A9E!0001!A2DF.8EC2!0008!79FE.3B0A' 2019-05-04 00:14:40,811 INFO [qtp804611486-13] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:262) - Authentication success for Client: '@!0B6C.CFA2.B551.6A9E!0001!A2DF.8EC2!0008!3DC0.E151' 2019-05-04 00:14:40,846 ERROR [qtp804611486-13] [org.xdi.oxauth.uma.service.UmaNeedsInfoService] (UmaNeedsInfoService.java:92) - Unable to load UMA script dn: 'inum=@!0B6C.CFA2.B551.6A9E!0001!A2DF.8EC2!0011!2DAF.F9A5,ou=scripts,o=@!0B6C.CFA2.B551.6A9E!0001!A2DF.8EC2,o=gluu' 2019-05-04 00:14:40,847 WARN [qtp804611486-13] [org.xdi.oxauth.uma.service.UmaTokenService] (UmaTokenService.java:103) - There are no any policies that protects scopes. Scopes: uma_authorization https://idp.mastersinweb.hosting/oxauth/restv1/uma/scopes/passport_access. Configuration property umaGrantAccessIfNoPolicies: false 2019-05-04 00:14:40,847 WARN [qtp804611486-13] [org.xdi.oxauth.uma.service.UmaTokenService] (UmaTokenService.java:108) - Access denied because there are no any protection. Make sure it is intentional behavior. 2019-05-04 00:14:40,849 ERROR [qtp804611486-13] [org.xdi.oxauth.uma.service.UmaTokenService] (UmaTokenService.java:135) - Exception happened org.xdi.oxauth.uma.authorization.UmaWebException: HTTP 403 Forbidden at org.xdi.oxauth.uma.service.UmaTokenService.requestRpt(UmaTokenService.java:109) [classes/:?] at org.xdi.oxauth.token.ws.rs.TokenRestWebServiceImpl.requestAccessToken(TokenRestWebServiceImpl.java:115) [classes/:?] at org.xdi.oxauth.token.ws.rs.TokenRestWebServiceImpl$Proxy$_$$_WeldClientProxy.requestAccessToken(Unknown Source) [classes/:?] at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source) ~[?:?] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_181] at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_181] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.21.Final.jar:3.0.21.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [servlet-api-3.1.jar:3.1.0] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1655) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:215) [websocket-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.xdi.oxauth.auth.AuthenticationFilter.processJwtAuth(AuthenticationFilter.java:389) [classes/:?] at org.xdi.oxauth.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:109) [classes/:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.gluu.oxserver.filters.AbstractCorsFilter.handleNonCORS(AbstractCorsFilter.java:344) [oxcore-server-3.1.6.Final.jar:?] at org.gluu.oxserver.filters.AbstractCorsFilter.doFilter(AbstractCorsFilter.java:121) [oxcore-server-3.1.6.Final.jar:?] at org.xdi.oxauth.filter.CorsFilter.doFilter(CorsFilter.java:104) [classes/:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.xdi.oxauth.audit.debug.ServletLoggingFilter.doFilter(ServletLoggingFilter.java:55) [classes/:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) [jetty-security-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.Server.handle(Server.java:503) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] ``` I'm kind of at a loss as to what to do here. It's just a server for testing purposes so no big deal if I need to re-install, however I rather figure out how to regain access and see what I did wrong here.
Ubuntu 18.04
closed

Answers

By Michael Schwartz Account Admin 03 May 2019 at 11:44 p.m. CDT

Copy
Michael Schwartz gravatar
see [reverting authn ](https://gluu.org/docs/ce/3.1.6/operation/faq/#revert-an-authentication-method)

By William Lowe user 04 May 2019 at 3:41 a.m. CDT

Copy
William Lowe gravatar
Also, does your server have valid ssl certificates? Super Gluu requires the Gluu Server to have SSL to work as expected. If you so have valid certs, your previous enrollment attempts could be affecting the new enrollment. You'll want to make sure your app has keys removed, and the server has no record of the device. Then re enroll . Also, you can enroll devices post authentication using our new app [Casa](https://casa.gluu.org)

By Ronald R. user 04 May 2019 at 4:57 p.m. CDT

Copy
Ronald R. gravatar
@Michael.SchwartzThanks for the answers. I found the reverting admin guide yesterday after posting however it didn't seem to work. I received an error that I used invalid credentials while I'm positive my password was correct. I tried the password with and without quotation marks and also with ' '. As I had just installed the server I decided it was better to start over. @William.Lowe That might have been the problem. While using SSL they where self signed instead of, for example, LetsEncrypt. I'm gonna start over again and hopefully get it right the second time. :)

By Ronald R. user 04 May 2019 at 6:19 p.m. CDT

Copy
Ronald R. gravatar
Brand new installation and managed to lock myself out, again. :( Like I said, I did a new installation (Ubuntu 18.04) and everything was well. I then decided before changing the authorization mechanism to get my SSL in order. I requested a LetsEncrypt certificate, copied the certificate and public key to /etc/certs, renamed the certificate and public key in the Apache virtual server config and restarted Apache. Now when trying to login I can see the new certificate in the browser, however after login I'm presented with the following message: ``` Something wrong happened. Login failed, oxTrust wasn't allowed to access user data ``` Clicking the back button loops me to the same message again. I can only get to the login screen again by clearing cookies etc. The oxauth.log shows the following: ``` 2019-05-04 23:06:05,670 INFO [qtp804611486-14] [org.xdi.oxauth.service.AuthenticationService] (AuthenticationService.java:533) - Attempting to redirect user: SessionUser: SessionState {dn='oxAuthSessionId=9c3bbf14-8f93-4b0a-ad67-6b4b60378546,ou=session,o=@!D4C8.540E.BBA1.FE99!0001!261E.050C,o=gluu', id='9c3bbf14-8f93-4b0a-ad67-6b4b60378546', lastUsedAt=Sat May 04 23:06:05 UTC 2019, userDn='inum=@!D4C8.540E.BBA1.FE99!0001!261E.050C!0000!A8F2.DE1E.D7FB,ou=people,o=@!D4C8.540E.BBA1.FE99!0001!261E.050C,o=gluu', authenticationTime=Sat May 04 23:06:05 UTC 2019, state=authenticated, sessionState='5b9efca1b3cd3ee6672e851e33c53032e446b3940441961a4327df978676bfb7.9714e576-068a-4ee5-834c-944fe926626f', permissionGranted=null, isJwt=false, jwt=null, permissionGrantedMap=org.xdi.oxauth.model.common.SessionIdAccessMap@5d416c6f, involvedClients=null, sessionAttributes={auth_external_attributes=null, opbs=3c3ec51e-da61-4f56-b902-aed56029462b, response_type=code, nonce=c557a362-2cd9-43e4-a609-d980abe52d80, client_id=@!D4C8.540E.BBA1.FE99!0001!261E.050C!0008!EBDF.21D5, auth_step=1, acr=auth_ldap_server, remote_ip=83.163.46.235, auth_user=admin, scope=openid profile email user_name, acr_values=auth_ldap_server, redirect_uri=https://idp.mastersinweb.hosting/identity/authentication/getauthcode, state=54254530-9510-49ca-a405-a69e3bbea349}, persisted=true} 2019-05-04 23:06:05,671 INFO [qtp804611486-14] [org.xdi.oxauth.service.AuthenticationService] (AuthenticationService.java:541) - Attempting to redirect user: User: org.xdi.oxauth.model.common.User@235d3550 2019-05-04 23:06:05,672 INFO [qtp804611486-14] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:409) - Authentication success for User: 'admin' ``` As far as I can see the authentication was successful, but something after that goes wrong. Any ideas on what might cause this? For the moment I'll try reverting back to old default certificate to see if that solves anything.

By Ronald R. user 04 May 2019 at 7:18 p.m. CDT

Copy
Ronald R. gravatar
After searching the error presented by the webUI I came across a post where it was suggested to add the certificate to the JVM keystore. I tried this with the following command: ``` root@localhost:~# /opt/jdk1.8.0_181/bin/keytool -import -alias idp.hostname -keystore /opt/jdk1.8.0_181/jre/lib/security/cacerts -file /etc/certs/idp.hostname/httpd.crt ``` Is this the correct manner to achieve this? And is this really necessary? On some posts there's suggested you need to add the certificate to JVM, however others suggest replacing the default Apache certificate is all that needs to be done. Unfortunately tough, adding the certificate to JVM and rebooting the server didn't do the trick and I'm still presented with the same messages. Any suggestions?

By William Lowe user 04 May 2019 at 11:33 p.m. CDT

Copy
William Lowe gravatar
I'm not 100% sure, but the docs state Ubuntu 14 and 16 are supported, not 18. I know we've been working on supporting 18, but I'm not sure if 3,1.6 does, and the docs indicate it does not.

By Ronald R. user 05 May 2019 at 5:26 p.m. CDT

Copy
Ronald R. gravatar
@William.Lowe Hi William, thanks for your reply. I have indeed seen the statement that only Ubuntu 14 and 16 are supported. However as in the manual there are Ubuntu 18 repositories being provided I figured it was just a glitch of the documentation not being 100% up to date. I'll have another go at it tonight with Ubuntu 16 to see if that makes any difference. Cheers.

By Ronald R. user 05 May 2019 at 6:04 p.m. CDT

Copy
Ronald R. gravatar
Okay, good news. I installed Ubuntu 16.04 with Gluu. I then proceeded to install the ACME v2 client for letsencrypt and created the certificates. I changed the Apache config to point to the new certificates and restarted apache. After these steps it did not yet work and I was presented with the same messages as before. I proceeded to add the certificate to the JVM keystore with: ``` root@localhost:~# /opt/jdk1.8.0_181/bin/keytool -import -alias idp.hostname -keystore /opt/jdk1.8.0_181/jre/lib/security/cacerts -file /etc/certs/idp.hostname/httpd.crt ``` After having issued this command I went out of chroot jail and restarted Gluu with: ``` service gluu-server-3.1.6 restart ``` This look a while to complete but afterwards everything worked. Thanks for the help.

Post an answer