I want to use multiple keytabs in multiple server threads. I don't want to use JAAS conf file so i implemented my own login configuration in LoginConfiguration class. The getGSSCredentials() function in KerberosLogin class is used to get the Credentials by giving keytab location as parameter.
KerberosLogin -> http://ideone.com/vaip3H
LoginConfiguration -> http://ideone.com/jDqlN0
When i ran only two server threads, first one was able to get the credentials from its keytab ( both the server threads use different service principal ) while second one failed. Somehow using parms.put("refreshKrb5Config","true"); in LoginConfiguration solved the problem.
I am not able to understand why it's not working without refreshing the configuration and for cases in which there will be several such server threads will it be safe to use. Is there any better way to use multiple keytabs ?
It was due to the way java6 handles login config, it has been fixed in java7.
Related
We have setup weblogic 12.2.1.4 clustered environment with 2 nodes in a cluster. We use session ID as part of authentication mechanism to log our user session info to the database. When both managed servers are up, the server generates this session ID:
MrvgJEMe6NG95XNsflnhsWjspl52GXPdl33whbIfGkgaEQm7Rk0X!1974917613!-533469515!1605782630842
When we tried to test session replication, by bringing down the server that currently serves the HTTP request, we have noticed that the session ID has changed and contains NONE as part of the generated ID.
MrvgJEMe6NG95XNsflnhsWjspl52GXPdl33whbIfGkgaEQm7Rk0X!1974917613!NONE!1605782630842
This has caused session replication inconsistency. Has anyone encountered the same issue and how did you resolve it? Your inputs are highly appreciated.
Thank you in advance for the help.
Enable the Debug Flags to Track Session Replication Failures
To gather more logging information about session replication failures, you should enable the flags DebugCluster, DebugClusterAnnouncements, DebugFailOver, DebugReplication, and DebugReplicationDetails.
To Enable:
In WebLogic Server 9.x and higher, the reccommended approach is to use the admin console. For each server in the domain, navigate to Servers -> -> Debug and enable the desired flag(s).
You can use the weblogic.Admin command line utility to dynamically turn the debug options on and off.
For example, to turn on DebugCluster on all administration instances of ServerDebug Mbean (i.e., Admin Server or a Managed Server):
java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -type ServerDebug -property DebugCluster true
Alternatively, you can edit the config.xml and the Mbean element in the stanza for each server that you want to debug and set the value to "true" to enable or "false" to disable. Then you must restart the Admin Server. Managed Servers will reconnect to the Admin Server and the debug flags will then dynamically take effect. Example:
At the end, with all the flags set, in your config.xml the ServerDebug tag would like below:
Make sure the stdOutSeverity level of the server is INFO and StdoutDebugEnabled is set to "true". The debug information will be logged into the server log as well as to the standard out.
Validate the Weblogic.xml entries
Make sure weblogic.xml has all the parameters that need to be set for each Session Replication type. For example, when using in-memory replication the sample weblogic.xml would look like:
I am trying to migrate an older 2.x server to 3.x due to the LDAPS connectivity requirement for a new AD tree/domain that is being created. I had to upgrade not only Freeradius but the server OS to support newer versions of TLS. I roughly had the configuration I think correct in 2.x, but cannot be 100% certain as authentication to the new AD tree structure was not completely working because of the SSL/TLS incompatibility. I am having a harder time with the new module configuration layout in 3.x.
The current 2.x performs authentication for 2 methods:
1) LDAP to the existing AD tree using a redundant server setup
2) SQL/PERL via a custom module.
The new 3.x server I need to perform 3 authentication checks via 2 methods:
1) LDAP to the existing AD tree using a redundant server setup
2) LDAPS to the new AD tree (possible redundant server setup)
3) SQL/PERL via the custom module
I have read that this may require templates for the LDAP configuration, but have not found any examples for that. Any help/guidance would be greatly appreciated.
The config is all in the LDAP module configuration file, raddb/mods-available/ldap - the ldap attribute map is in there, too.
To connect to two different LDAP servers, create two instances of the ldap module, e.g. where you have
ldap {
...
}
add another copy of that config with
ldap ldap-new {
...
}
then you can call ldap or ldap-new as appropriate in the server where needed to query the required LDAP server.
Make sure you create the appropriate symlinks to enable the module, e.g. raddb/mods-enabled/ldap -> ../mods-available/ldap.
You can certainly use templates to save duplicating config, but to begin with it's a lot easier to just copy the ldap config file, change the instance name in the new file and then tweak from there. Templates are likely to make things more confusing unless you know what you're doing.
I've created Web Application running on Java Liberty Runtime on Bluemix. Login is done by using SSO service with SAML enterprise provider. After login user redirected to my app and on every JAX-RS request I get user's credentials by following code:
Subject s = WSSubject.getCallerSubject();
Object credential = s.getPrivateCredentials().iterator().next();
String loginToken = credential.toString();
Everything works fine, but if the user has been idle for more then 10 minutes and then perform any ajax request WSSubject.getCallerSubject() returns null, and I required to refresh application.
I've tried to increase timeout by adding following attribute to web.xml:
<session-config>
<session-timeout>60</session-timeout>
</session-config>
But it didn't help. So I'm looking how can I increase timeout or possible I can retrieve user credentials in a different way?
You need to add the optional element <authCache> to the server.xml file to change the default values for the authentication cache.
As you mentioned in your question, the default value is 10 minutes. To change it to 60 minutes you need to include the following in the server.xml file:
<authCache initialSize="50" maxSize="25000" timeout="60m"/>
The documentation here provides more details and also explains initialSize and maxSize options, I left the default value for these two above and just updated timeout.
If you are deploying your application using the default method of pushing the war file, you will need to use a different approach to deploy the application with a custom server.xml file. Please check the documentation here for options on pushing Liberty profile applications (more specific check sections Server Directory and Packaged Server).
In this case, you may also want to check the server.xml file that is currently deployed and modify that version to add the <authCache> element.
You can get a copy of the file by running the following command:
$ cf files <your_app_name> app/wlp/usr/servers/defaultServer/server.xml
I am using httpinvoker in JBoss 4.0.4 (little old) for EJB invocations.
Since there are so many clients that make calls to my server, I want to identify the clients for each call in server.
Is there a way to do this with JBoss httpinvoker?
I could imagine adding a header to identify my client in each HTTP request, but cannot find a way to add a header in httpinvoker.
Auditing builds on a name, and thus on an authentication scheme somehow.
Therefore I suggest using the standard client authentication infrastructure to solve your problem. This works for RMI as well (it's not bound to HTTP), and the user ID is even passed down into your EJBs.
Server
Put the EJB in a security-domain (ejb.jar: META-INF/jboss.xml)
You could use the application-policy other which just the UsersRolesLoginModule (conf/login-config.xml); this is the default policy, it's already configured.
Add users.properties and roles.properties to your ejb.jar file (top level package): These are used by the UsersRolesLoginModule
For each user, add his name and a (dummy) password to users.properties
Client
Create a callback class which implements a javax.security.auth.callback.CallbackHandler: This callback is used, when the authentication needs the user and the password.
Create a javax.security.auth.login.LoginContext; pass the callback handler as the 2nd argument; call login() on the instance of the LoginContext
Connect normally to the EJB server using an InitialContext
Add -Djava.security.auth.login.config=.../jboss-4/client/auth.conf when you start the client
This way a user ID is passed from the client to the EJB (as part of the standard authentication process). Now, in the EJB methods, you can get the user ID by calling getCallerPrincipal() on the SessionContext instance. I have tested this against JBoss 4.2.3
Additional information: JBoss client authentication
Addendum 1:
Using RMI or HTTP, the password is not transported in a secure way. In this case just use a dummy password, this is OK for auditing.
On the other hand, if you use RMI over SSL or HttpInvoker over HTTPS, you could change to a real and secure authentication quickly.
Addendum 2:
I am not sure, if it works without defining roles. Possibly you have to
Add a line in roles.properties for each user: Add a connect role, for example
Add role definitions in ejb-jar.xml as well: security-role-ref for each EJB, and security-role and method-permission in the assembly-descriptor
Update
As there is already a login module, there might be another possibility:
If you have the source code of the login module, you could possibly use another TextCallback to get additional information from the client (in your case a user ID). The information could be used to create a custom Principal. Within the EJB, the result of getCallerPrincipal() could be cast to the custom principal.
I am using Confluence 4.2.5 (build 3284) with CAS SSO connected to my LDAP server and would like to be able to call synchroniseUserDirectories() from the LDAP server when a user changes their password so that the change is instantaneous.
The way it works now is that users have to wait for the Confluence to run it's periodic LDAP synchronization which can be disconcerting for them.
I have tried using the XML-RPC interface to call changeUserPassword() (as an administrator) but it doesn't work. The operation raises an exception "Error changing password for user ...". I presume that that is because the user is defined in the LDAP but I can't tell for sure because the exception message wasn't clear about the cause.
Here is example code that I would like to be able to use. It doesn't work.
#!/usr/bin/env python
import xmlrpclib
url = 'https://docs.example.com'
admin_user = 'frobisher'
admin_pass = 'supersecretstuff'
username = 'bigbob'
new_password = 'bigbobsbigsecret'
server = xmlrpclib.ServerProxy(url + '/rpc/xmlrpc')
token = server.confluence2.login(admin_user, admin_pass)
# CITATION: https://developer.atlassian.com/display/CONFDEV/Remote+Confluence+Methods
# this doesn't exist but would be my preferred approach.
# It raises a NoSuchMethodException exception.
server.confluence2.synchroniseUserDirectories(token)
# this throws a general exception, because of the LDAP? The message
# wasn't clear about the source of the problem.
#server.confluence2.changeUserPassword(token,
# username,
# password)
server.confluence2.logout(token)
Is there any way to do this using SOAP or REST? I was concerned about REST because it sounds like it is still a prototype.
If none of those approaches will work, can it be done with a simple plugin considering that this must be a push operation from the LDAP server to the Confluence server? I have no experience writing plugins but I do some java work occasionally.
Any hints would be greatly appreciated.
The short answer is "no". The ability to synchronise remote user directories is not exposed as a remote operation in Confluence.
The long answer is "yes", you can write a plugin to do this. If you're already familiar with java, then perhaps the best answer is to just show you some source code I've written that performs a similar function: https://bitbucket.org/jaysee00/confluence-user-sync-api This plugin gives you SOAP, XML-RPC and JSON-RPC methods to force an individual user account to be synced in to Confluence from a remote directory.
That might suit your purposes as-is, but I imagine it would be possible to edit the source of this plugin and change it to synchronise an entire directory, too.