Every time I connect to a repository the credentials are stored in the user's home folder under the .subversion directory (UNIX systems). Is there anyway not to do this, or at least specify another directory something like --config-dir option under the command line?
I made a little hack that is change temporarily the user.home java property, but this doesn't work on Windows.
Thanks in advance,
Rui
One of the createDefaultAuthenticationManager() implementations allows this.
It is a static method in org.tmatesoft.svn.core.wc.SVNWCUtil.
Here is the description from https://svnkit.com/javadoc/
public static ISVNAuthenticationManager createDefaultAuthenticationManager(java.io.File configDir, java.lang.String userName, java.lang.String password, boolean storeAuth)
Creates a default authentication manager that uses the provided configuration directory and user's credentials. The storeAuth parameter affects on using the auth storage.
Parameters:
configDir - a new location of the run-time configuration area
userName - a user's name
password - a user's password
storeAuth - if true then the auth storage is enabled, otherwise disabled
Returns:
a default implementation of the credentials and servers configuration driver interface
So, you could do something like.
...set up repository...
File configDir = new File("MyFolder");
ISVNAuthenticationManager auth;
auth = SVNWCUtil.createDefaultAuthenticationManager(
configDir, user, password, false );
repository.setAuthenticationManager(auth);
Related
I am creating a NodeJS API server that will be delegatiing authentication to an oauth2 server. While I could store the key and secret along with the source code, I want to avoid doing that since it feels like a security risk and it is something that doesn't match the lifespan of a server implementation update (key/secret refresh will likely happen more often).
I could store it in a database or a maybe a transient json file, but I would like to know what are the considered the best practices in the NodeJS world or what is considered acceptable. Any suggestions are appreciated.
One option would be to set environment variables as part of your deployment and then access them in the code from the global process object:
var clientId = process.env.CLIENT_ID
var clientSecret = process.env.CLIENT_SECRET
Since I wanted to provide something that can store multiple values, I just created a JSON file and then read that into a module I called keystore (using ES6 class):
class KeyStore {
load() {
// load the json file from a location specified in the config
// or process.env.MYSERVER_KEYSTORE
}
get (keyname) {
// return the key I am looking for
}
}
module.exports = new KeyStore();
I would ideally want to store the file encrypted, but for now I am just storing it read only to the current user in the home directory.
If there is another way, that is considered 'better', then I am open to that.
I'm a newbie to JAAS and I still can't get one thing: what if a malicious user creates the subject and principal manually ?
Shouldn't there be some validation of subject/principal in case the user has tampered with it ? None of the tutorials I've seen even mentions this.
Look at this example (ch02 from jaasbook.com):
SimpleCallbackHandler cb = new SimpleCallbackHandler(username,
password);
LoginContext ctx = new LoginContext("chp02", cb);
ctx.login();
Subject subject = ctx.getSubject();
System.out.println("Logged in " + subject);
Subject.doAsPrivileged(subject, new PrivilegedAction() { ...
And if I replace this code with this one:
Subject subject = new Subject();
Principal p = new SysAdminPrincipal(username);
subject.getPrincipals().add(p);
Subject.doAsPrivileged(subject, new PrivilegedAction() { ...
it works just as well (at least in this sample code).
I must have missed sth obvious otherwise it would make no sense to use jaas at all.
Thanks
The distinction is between trusted and untrusted code.
If you allow code to run within the JVM that you do not trust then you need to protect the JVM with a configured Policy and running with a SecurityManager enabled. This is akin to the Java Applet environment. Within such an environment you will typically lock down parts of the codebase such that only code from trusted sources, and optionally cryptographically signed, can run, or call, other parts of code.
Within Java security, when a permission check is made the entire calling stack is checked to ensure that every part of the stack is allowed to use the permission.
In this case, you are starting a PrivilegedAction which associates a Subject to the AccessControlContext. If you look into the sourcecode you'll see that performs a permission check:
javax.security.auth.AuthPermission "doAs";
In the default Java security policy, the only code which can do this are installed Java extensions, so if you want to do this in your own code, with a running SecurityManager, you will need to manually set this permission.
So, the Subject class is unprotected because it is of no affect unless its associated with an AccesssControlContext.
The AccesssControlContext is protected by an AuthPermission.
The setting of AuthPermission is protectectd by the security Policy and SecurityManager, which are configured at JVM startup.
In this case, if you run with no SecurityManager, or a custom Policy which grants an AllPermission to any codebase, and you allow untusted code to run, then you have a big security problem.
If you want to run untrusted code and assign Subjects to AccessControlContexts then protect the code which does this will something like the following policy file:
grant codebase "file://home/me/myapp.jar" signedby "me" {
javax.security.auth.AuthPermission "doAs";
}
This protects that only your codebase, including the call stack, can perform the Subject assignment.
Or just make sure that you trust the code you deploy to your app...this is the 99% deployment scenario where most applications are protected within their host environment and do not allow remote code to be executed.
I have a need to write a .NET application which will query Active Directory while running in Windows PE on a computer which is not yet a member of the domain.
We are running this during a Microsoft Deployment Toolkit task sequence (note that MDT 2012 has been configured to load support for .NET into the WinPE environment - the .NET application is starting without any problems).
I am using the code below to bind to the domain:
DirectoryEntry entry = new DirectoryEntry(
path,
username,
password,
AuthenticationTypes.ServerBind | AuthenticationTypes.Secure);
I have tried a path both of the form:
LDAP://domainServer/dc=domain,dc=name
And also without a domain controller name as
LDAP://dc=domain,dc=name
I have also tried using a username both of the form domain\username and also just username.
The DirectoryEntry object seems to be constructed okay, but when I try to execute Console.Writeline(entry.Name) to confirm a valid connection has been made, I get the following exception:
System.Runtime.InteropServices.COMException (0x80005000): Unknown
error (0x80005000) at
System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind() at
System.DirectoryServices.DirectoryEntry.get_Name()
I have tried other variations on this code, trying to execute LDAP queries with various filters, trying to rewrite it in VBScript, etc... but the code posted above is the simplest example I could come up with which reproduces the problem.
From what I have read, in a scenario like this you would always need to use AuthenticationTypes.ServerBind and that is why I am trying to specify the code within the ADSI LDAP path. But what is wrong with the code above? To me, it looks like it is passing all needed information in the parameters to the DirectoryEntry constructor.
There is a way to get it work, but it's not supported by Microsoft. This post helped me a lot. It works, tested and approved for a deployment of new computers :)
Get the ADSIxXX.inf from the zip file to C:\ADSI
Copy the following files from a Windows/System32 to C:\ADSI. Carefull of Architecture
x86 x64 -
adsldp.dll
adsmsext.dll
adsnt.dll
mscoree.dll
mscorier.dll
mscories.dll
Mount the bootimage.wim
No need to load Package (Your WinPE is already configured to load .NET API), juste add ADSI driver:
Dism /Image:C:\Mount /Add-Driver /Driver:C:\ADSI\ADSIxXX.inf /forceunsigned
No need to load his script
Unmount the bootimage.wim
Then it's done, if your .NET application is well implement ;)
I'm not sur the PIPE | is supported as an argument too, just set to AuthenticationTypes.Secure -
DirectoryEntry entry = new DirectoryEntry(
path,
username,
password,
AuthenticationTypes.ServerBind | AuthenticationTypes.Secure);
Link: http://www.deploymentresearch.com/Research/tabid/62/EntryId/74/ADSI-plugin-for-WinPE-4-0.aspx#AddComment
I'm working on a project where I'm trying to implement authentication against external user base for customers, this seems to be working correctly.
Recently there has been added another requirement that some people (not present in the aforementioned base) need to be able to edit parts of pages' content. First thing that comes to mind is to have separate ORM/File Auth driver enabled for those few editors to be able to authenticate them separately.
Is it possible to use two Auth drivers at the same time in Kohana 3.2?
Yes, you can use different drivers at once. Just create another instance instead of standard singleton:
// default Auth
$config = Kohana::$config->load('auth');
$auth = new Auth($config);
$user = $auth->get_user();
// special Auth for administration
$config2 = Kohana::$config->load('admin_auth');
$auth2 = new Auth($config2);
$admin = $auth2->get_user();
Restrictions:
You must use differ configs (driver and session_key values must differ). Note that some settings are defined in classes and cant be changed by config (for example, "remember" cookie named authautologin).
You cant share default ORM models (Model_User, Model_Token, Model_Role), because their names are hardcoded. But ORM driver & File driver can be used.
Kohana's Auth module does not natively support using two Drivers.
However, you can implement a new Driver yourself very easily. You can follow the instructions for creating a new Driver by copying the existing driver and modifying it, here: http://kohanaframework.org/3.3/guide/auth/driver/develop
The simple thing to do would be to put the following logic in your _login method:
Check the external user database for a valid login
If there is a valid user in the external user database, return true.
If there is no valid user in the external user database, check the local user database instead.
If the user exists in the local database, return true.
I'm looking for a way to query the Terminal Services Home Folder property of user objects in Active Directory. My goal is to be able to perform a reverse lookup, finding the user(s) that use a particular home folder.
Normally to perform a search I would do something like this:
using (var search = new DirectorySearcher())
{
// Find a user based on their telephone number
search.Filter = "(telephoneNumber=999)";
search.PropertiesToLoad.Add("displayName");
var result = search.FindOne();
if(result != null) {....}
}
But the Terminal Services settings don't seem to have a referable LDAP attribute name - in the past to set these values I've had to use the IADsTSUserEx interface with an existing DirectoryEntry to manipulate the TS profile and home folder properties. However this is only useful when I have the user account in question - it's not very practical to step through every user in a domain and create a DirectoryEntry object for them just to check their TS profile path.
Is there any practical way to perform a "WHERE User.TerminalServicesProfilePath=X" query in .NET?
Nobody here so, I try an explanation.
In Windows Server 2008 (and R2), the Terminal Services Terminal Server Runtime Interface takes the user parameters from the user Active-Directory attribute called userParameters. As explain in Microsoft documentation userParameter contains Terminal Server parameter as blob.