I've been mucking around with GlassFish v3 prelude this evening. A couple of things I'm not sure about is how the security works.
It installed like a dream, so the first thing I did was remove the anonymous account and setup an "admin" account with "mysecretpassword" and specified the asadmin group for this user in the admin realm.
At that point the stop-domain command stopped working from the console (and/or start menu shortcut). Fair enough, but the stop-domain command accepts a --user argument but then wants a --passwordfile path supplied which I didn't know where it was.
After some googling I chanced upon asaadmin login -p 4848 which created a password file in my documents and then stop-domain started working!
So the questions:
1) Is it possible to get stop-domain to prompt for a user/password?
2) This whole business of having a file with a (hashed) password doesn't sound great to me - why did they do it this way, and is it transferable, can it be disabled and if it can, how then do I stop the domain?
3) How do security realms work - as in what are they, and how do they differ?
4) What's the best resource (book, website, whatever) on GF v3?
Glassfish relies upon a "master-password" file which is used to control access to the core admin commands (notably asadmin).
This master password is used to encrypt assorted bits within the GF system and configuration. By default, it's store in the file $domain-dir/master-password.
If that file exists, then asadmin will not prompt for a password to make changes. If it does not exist, then it will prompt you. If you ever change the password, the system will automatically recreate this file.
Note, this isn't a role based thing, it's simply a password to the entire system.
So, that's the core password.
Next is the actual admin password.
When you create a domain, it asks you for an admin name and password. This information is stored in ~/.asadminpass file.
So, in the simple case of a local install, you can use asadmin without passwords or user information.
If you delete that file, then you will be prompted for a user and password.
The admin passwords are managed in the "admin-realm" within the app server.
Realms are a Java EE construct used to represent authentication and authorization stores.
Realms provide user name, password, and role information.
By default GF uses file realms for its security information. Out of the box you have a "admin-realm" which is for users of the admin console. There is also an empty "file" realm for use by applications. Out of the box, Glassfish also supports and LDAP realm and a JDBC realm where credentials are stored in an LDAP and RDBMS respectively.
The Glassfish website and forums are currently the best resources available for this. It's a bit of a muddy time as v3 is still being worked on (v3 Prelude is just that, a prelude to the final release later this year), but there is still a lot of overlap with v2.
GlassFish v3 Prelude Domain Start Failed
first think stop any one server which is running in system --
Exam:- suppose you using glass fish server and netbeansIDE both are working on your system so when you want compile your application so that time you can stop your glassfish server then compile and run your application within netbeans IDE it's working
Related
Using the google app engine maven plugin when a deploy is performed, the browser opens and an oauth key is copied.
However, I want to use two different google accounts from the same laptop and have laready previously registered one oauth key, but now want to use another. I never get prompted for a key and the deploy fails as the application id is not correct, which is expected.
Is there any way to use two different google accounts with app engine sdk ?
I can deploy the app OK using a different machine as it is setup with the correct account.
(this would not be a problem if push to deploy/pipeline worked, but it doesn't)
To have more than one account register with the SDK, you should use gcloud Command Line Tool.
Once you have login multiple accounts, $ gcloud auth list should yield a list of accounts. Switching is as simple as running $ gcloud config set account ``ACCOUNT'' which should make relevant tokens active and will allow you to use appcfg.[py|sh] with the selected account.
If you look in your home directory, you should find a couple of files used by appcfg: .appcfg_oauth2_tokens_java and .appcfg_cookies. Deleting the former (I think) will prompt appcfg to retrigger the oauth process.
So... I guess if you have multiple oauth token files, you can create a short shell script that takes the username as an argument then copies the oauth token file you need to .appcfg_oauth2_tokens_java just before the appcfg update.
I would like to use the existing user accounts on my redhat server for users to login with.
The redhat server uses active directory to authenticate with, but I cannot get access to authenticate with AD directly.
My web app will be using spring security.
Is it possible to use the redhat server's user accounts to authenticate against with spring security?
(note: su does not support passwords given on the command line with my server ("-S")).
I was digging around but could not find a sample code, but you could use PAM.
I found this project in GitHub https://github.com/kohsuke/libpam4j, which is a Java implementation of PAM (I don't know if it is active or if it will provide what you need).
Also, if sudo doesn't support passwords, you could try with expect
spawn "/bin/su" "bob"
expect "Password:"
send "userspassword\r"
expect "^\\$"
send "ls"
expect -re "^\\$"
send "exit\r"
expect eof
I'm using a program that adds correctly a user to AD using LDAP protocol.
I noticed that there are some properties about the password. There are userPassoword that stores password in clear and unicodePwd that accepts encoded pwd.
I'm working in a project where a lot of users were created by the admin in AD, using Windows server administration tool. But what suprise me more, is that these users have password and the app workws fine with the login...but BOTH properties are empty! So, where are the password?
By Java I have to add the passwords in the same way, but I cannot figure out how to approach the problem, because I don't know where those users' password are stored.
Any ideas?
You cannot read a password from AD. There is special logic in the directory to handle writes to those attributes, but, there is no read capability. They will always appear to be null.
Can somebody work on jaas login modules. I was going through docs & my understanding is there is ntlogin module, unix login module comes with sun-jdk.
I want to is these login module can
1. Authenticate with OS users
2. Provide groups of that user.
basically I want to authenticate with os. Input is username, password & group name. I want to know if username, password combination is right & user belong to that group.
I want to authenticate with windows & popular linux distros such as RHEL, Suse, CentOS.
I dont want to do LDAP authentication only os authentication.
For windows, there is waffle library available. But I am not able to authenticate when using 64bit machine. On 32bit it runs fine.
For linux, there is jpam, but it doesn't give group. It will just check username, password combinateion.
As far as I remember JAAS is about Java code and vm related authorization: is current running code authorized to do something?
I think it's easier to use some os native wrapping scripts to authenticate user and then just extract user info in your Java code.
I was looking for the same thing. So far I've found that the Unix "login module" actually doesn't do any authentication; it creates Principals for the process' owner's user and group, and adds them to the Subject. This makes it fairly useless for, say, authenticating webapp sessions.
You are going to need native code to authenticate OS credentials, but it should be possible to hook that into JAAS. It makes sense to make that native code into a small and simple external helper program (like one of the many 'checkpasswd' programs that come with similar frameworks to solve the same problem) because it will need elevated privileges to gain access to the stored keys.
I'm using GSSAPI in Java in order to login to an LDAP server using Kerberos authentication. I'm a newbie to Kerberos, so I'm sorry if this is an obvious question, but I couldn't find anything clear enough on the internet.
I perform the following steps:
Define Login configuration by setting the system property "java.security.auth.login.config" to the configuration file path.
Call LoginContext.login() with the name of the configuration and a self defined callback handler
In case login succeeded, "pretend to be" the subject (by using Subject.doAs()), and connect to the LDAP server by creating a new InitialLDAPContext with the appropriate environment variables.
Now, My problem is I don't understand which step correlates to which kerberos action?
Is it correct to say that after the login action I only have a TGT? When do I get the service specific ticket?
Thanks,
Dikla
The class com.sun.security.auth.module.Krb5LoginModule is Sun's implementation of a login module for the Kerberos version 5 protocol. Upon successful authentication the Ticket Granting Ticket (TGT) is stored in the Subject's private credentials set and the Kerberos principal is stored in the Subject's principal set.
(Taken from here)
This means that LoginContext.login is indeed equal to kinit in that after each of them, we have a TGT.
The service ticket will be obtained and used later - according to the action performed in Subject.doAs().
Never use LoginContext.login because it doesn't support MIT Kerberos cred cache standard for popular OS like Windows, Linux, MacOSX and etc.
JavaAPI is proprietary feature for Oracle environment
kinit and MIT is C libraries and no one alternative replaces it.
If you need specific TGT service to do correctly it's only to use kinit source code to make your own module.
Of course you must also use right way to get TGS without Java modules.
Never use Jaas and krb5Module in Linux/Windows.
Only Sun GSS native is fit for any OS: https://docs.oracle.com/en/java/javase/11/security/accessing-native-gss-api.html
This is important unless you don't want to make your KDC servers failed by thousands of requests flood.