Remove Password From Wildfly Console for local server

[George Berish]

Hi,

With apologies, I have to say that Wildly is the least intuitive, most poorly documented piece of software I can remember encountering. Those developing it seems more like a closed cult than a group intent on seeing it widely used.

With that said, I'd like to know how to remove the need for a password from the console for my local development Wildfly. There is no need for it, because there is no access to it by anyone other than me on my private PC. And Logging in every time is getting to be a real pain.

Thanks for any help.
glb

[Tim Holloway]

Oh, I've seen plenty worse when it comes to poor documentation. If it's hard to understand, it's because WildFly now comprises so much - the original JBoss way back when was pretty straightforward.

JBoss uses JEE-standard security realms to manage access to webapps, and that includes the console webapp. Having security turned off by default (or minimized) is what get Microsoft into trouble repeatedly back when "Windows Security" was a blatant oxymoron. And while JEE container security is mostly external, I'm fairly sure that if you completely yanked Realm control off your console all that the app would break.

The obvious alternative would be to use a "no-password" Realm on it, but I don't recall such an animal being part of the pre-supplied set of Realms. Although some of the Single-Signon Realms can attain the same net effect by pre-authenticating via your OS login. Still, hardly worth the effort.

What I usually do is a lot less subtle. I create an account with a 1-letter password.

Then again, Firefox can remember my credentials if I let it, so I really don't care what the userid/password is most of the time that I work with non-sensitive sites, be they my own or others. I just let my browser fill in the login and all I have to do it hit "Enter".

[George Berish]

Hi Tim,

Thank you for the suggestions.

[Although I'm still at a loss for a worst documented major software. Grin ... but that's just me.]

So ... I was all reconciled to just going with you suggestion -- a one letter id and password
... but Wildfly decided to bite me in the pants instead.

I decided to install it again from scratch.
I changed the config files to permit a one letter id and pw (something you didn't mention was required).
I was happy.
I closed Foxfire.
I opened it again
went to http://localhost:9990/console/App.html
Tried to log in.
Was greeted (or repelled with)

"ACCESS DENIED Insufficient privileges to access this interface."

Not really enjoying Wildfly yet, so if you have any suggestions I'd appreciate them.

It really does feel like Wildfly is more a cult intent on minimizing its inner circle than a software its developers hope will see wide use.


glb

[Tim Holloway]

I'll admit that the last time I tried to re-register for WildFly support they had a "captcha" that was so poor I never got in. While ironically a lot of spammers apparently did

But your latest problem sounds like straight old J2EE, not WildFly-specific.

The J(2)EE Container Authentication and Authorization system requires information from 2 sources. The first one is the userid/password source. The second one is the userid/role source. These sources can be LDAP entries, 2 database tables (or 1 combined table), or whatever is appropriate for the Realm that you're using to secure your system, but they must exist, and in fact, something did exist when you unwrapped your shiny new copy of WildFly. And I'm presuming that you then added your 1-character userid/password to the first of those 2 sources.

The second source is critical as well, since it provides roie-based access control. A Realm-authenticated user can be assigned zero or more roles that determine what parts of a webapp he/she is allowed to access. For example, I've done apps where the administrator role allowed system maintenance, the "clerk" role alllowed data entry, the "auditor" role allowed the ability to look at data but not enter it, and so forth.

So it is with the WildFly admin webapp. You need to create role entries that allow your shorthand userid to do what you want to do. You can look at the existing database and simply repeat what the original admin user was allowed or you can read the WildFly docs and determine what roies you want to set per the official instructions.

In case this extra refinement might seem silly, consider that depending on how things are configured a user might log in once for access to multiple webapps. In such an environment, you wouldn't want just anyone to be able to go in and mess around with WildFly system settings, you'd want only authorized users. Some system, such as recent Tomcat releases even allow delegation of certain functions so some people might have limited admin capabilities, as in the stuff I mentioned above.

[George Berish]

Hi Tim,

Thank you for your time and help. I'll go slog through a minimal course on server security ... even though I have no need for it.

I just needed Wildfly to tryout some stuff that someone else will someday have to deploy ... although for now the stuff lives in an environment where no one else has access.

But to clarify:
I reinstalled a brand new out of the box Wildfly just to clear out any junk I may have added to its over zealous security code.
I remembered to edit add-user.properties so I could use a short pw/id
I went to the console and obediently obeyed its demand I password protect access. (so far so good)
I poked around in the console (9990) to see what the Administration Tab did.
Wildfly told me I had to run the following code to use that Tab.

/core-service=management/access=authorization:write-attribute(name=provider,value=rbac)

So I used the CLI to do as told. (so far so good)
It gave me access to the Tab.

Then went away.
Then came back.
Now I'm locked out of the console entirely. (so far ... not good.)

So if you wouldn't mind, I'd much appreciate your just confirming whether I can reclaim control by modifying stuff in standalone-full.xml
... or if I need to reinstall again.
Right now, http://localhost:9990/console/App.html gets me nothing but rejected

For what it's worth. The biggest problem I've had with the forums everywhere is how often people on the inside offer advice (I assume is great) on what to change
... without giving even a hint of where the heck it get's changed.

Take for example you note:
... "You can look at the existing database and SIMPLY repeat what the original admin ...."
Yep. No doubt I could.
Grin ... Just let me google "existing database" to see what you meant.

Thanks again,
I do appreciate your time,
and ... this too shall pass,
glb

[Tim Holloway]

Actually, I usually try to be explicit on things such as resource paths, but I figured if you'd already edited it, you knew where it was.

I just had a look at the WildFly 8 documentation around this area: https://docs.jboss.org/author/display/WFLY8/add-user+utility

It has been a while since I've worked in detail with that stuff, so I've been relying on what other servers do and that sort of bit me here, as it appears that they're now trying to make WildFly itself handle user accounts instead of something like the more general mechanisms I'm used to seeing elsewhere. Alarmingly, this particular version doesn't seem to have built-in support for database-based user account info and its preferred "database" appears to be the property files.

Actually editing those files directly is something best done by people who understand how it all fits together. You would have been better off using the add-user utility program. That would have created your 1-character userid, allowed you to set a 1-character password and assign the necessary role ("Administrator"). Incidentally, the acronym "rbac" stands for Role-Based Access Control.

[George Berish]

Hi Tim,

I appreciate your staying with this. Thank you.
At a minimum I know I'm not going crazy.

Anyway ... sorry, but No. You can't use a 1 letter id and pw unless, and until, you first edit the add-user.properties file that arrives all set up to require 8 characters w/ 1-digit, 1-alpha and 1-special. So I can't stay out of there.

But ... I couldn't agree more with
"Actually editing those files directly is something best done by people who understand how it all fits together."

I mean that is what I did the first time. Stayed out. Used add-user.bat to create the id and pw demanded by Wildfly. And ... ta dum ... when done I was told by Wildfly that I could not see the ADMINISTRATOR tab unless I executed the code I showed earlier in the CLI.

Catch was that when I executed the code
... Wildfly told me I now lack the credentials to even see the Console anymore ... at all ... ever.

It just did it again when I ripped it all out and reinstalled

So I really think it fair to say
-- Wildfly is a club intended for people whose primary job is deployment that is next to useless for folks whose primary interest is in developing with Java code, and
-- Glassfish is the reverse.

So unless you have a better suggestion, I don't see as I have any option but to scrap the idea of using Wildfly for a few years. And go back to Glassfish.

Thank you again. I hope this info at least helps anyone else considering Wildfly.

glb