Authentication against VDS LDAP - authentication

I want to authenticate user against VDS(virtual directory server) using Java.
How VDS is different from LDAP? Or VDS is also working on LDAP
protocol?
Please help with any sample Java code for authentication against VDS
A sample code to authenticate against LDAP is as below
String userName = "John P R-Asst General Manager";
String passWord = "asdfgh123";
String base ="OU=SOU,DC=example,DC=com";
String dn = "cn=" + userName + "," + base;
String ldapURL = "ldap://mdsdc3.example.com:389";
authEnv.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
authEnv.put(Context.PROVIDER_URL, ldapURL);
authEnv.put(Context.SECURITY_AUTHENTICATION, "simple");
authEnv.put(Context.SECURITY_PRINCIPAL, dn);
authEnv.put(Context.SECURITY_CREDENTIALS, password);
try {
DirContext authContext = new InitialDirContext(authEnv);
return true;
} catch (NamingException namEx) {
return false;
}
To authenticate against VDS, is a complete dn required. Because as per experts only username and password needs to be send to VDS. It will automatically find its DN and do the authentication.
Will be thankful if anyone provide nice reference material regarding ldap and vds

A virtual directory server is a type of server that provides a unified view of identities regardless of how they are stored. (Or you may prefer Wikipedia's definition: "a software layer that delivers a single access point for identity management applications and service platforms"
LDAP is a protocol (hence the "P") for communicating with directory servers.
There isn't a necessary link between LDAP and a VDS, but it is likely that a VDS provides and LDAP interface and, potentially, other programmatic interfaces (Kerberos in particular comes to mind). The details of how you communicate with the VDS are going to be dependent on the configuration you are trying to talk to, but LDAP is a good bet.
Regarding needing a full DN, you don't even need a full DN to authenticate against plain Active Directory. The more usual mode would be to supply something like DOMAIN\username (using the sAMAccountName) or username#dc.example.com (that is, the user principal name) as the SECURITY_PRINCIPAL. In your example, the user would need to type John P R-Asst General Manager rather than anything they are likely to regard as their "user name."
You do, however, need to work out what the VDS you are trying to communicate with requires as the user name. Does it need DOMAIN\username, something else? These are details that whoever runs the VDS you are communicating with should be able to provide you.
In code, you should wind up with something like this (assuming you can use LDAP):
String userName = "DOMAIN\johnp";
String passWord = "asdfgh123";
String ldapURL = "ldaps://vds.example.com";
authEnv.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
authEnv.put(Context.PROVIDER_URL, ldapURL);
authEnv.put(Context.SECURITY_AUTHENTICATION, "simple");
authEnv.put(Context.SECURITY_PRINCIPAL, username);
authEnv.put(Context.SECURITY_CREDENTIALS, password);
try {
DirContext authContext = new InitialDirContext(authEnv);
return true;
} catch (NamingException namEx) {
return false;
}

Related

Automatically choose Auth0 DB Connection according to user's email address

I already read the multi-tenancy guide published, and I believe the solution I require for my app would be to create a separate DB Connection for each organization that I sign up.
My issue is that, since I'm going to be setting the connection parameter to a different name per client, I would have liked Universal Login to automatically determine the DB Connection name according to the user's email address. So, instead of the user manually providing some kind of a hint to which DB Connection I should authenticate them against, I would like to automatically determine that somehow.
Is there any way to do this?
I am assuming that you are using hosted login page. The easiest way to determine the connection based on client would be to pass the connection parameter when redirecting to /authorize endpoint. Thus, Lock will use the connection parameter passed in the URL as the connection to validate the user. For example:
https://[tenant]/authorize?
client_id=K8B5DJdStcZtUzbhaxAOzCrXNbo2kmXG&
response_type=token%20id_token&
redirect_uri=http://application_url&
scope=openid%20profile%20email%20&
connection=connection_name&state=123&nonce=345
Both auth0.js and auth0-spa-js can be used to pass the extra parameter(connection).
Second approach would be to use connectionResolver options if you are using Hosted Login Page+ Lock .
connectionResolver {Function}: When in use, provides an extensibility point to make it possible to choose which connection to use based on the username information. Has username, context, and callback as parameters. The callback expects an object like: {type: 'database', name: 'connection name'}.
var options = {
connectionResolver: function (username, context, cb) {
var domain = username.includes('#') && username.split('#')[1];
if (domain) {
// If the username is test#auth0.com, the connection used will be the `auth0.com` connection.
// Make sure you have a database connection with the name `auth0.com`.
cb({ type: 'database', name: domain });
} else {
// Use the default approach to figure it out the connection
cb(null);
}
}
}
Instead of username, you can take advantage of context object to identify the client (context.clientID) and choose the connection.

How can I search for ldap fields when using ActiveDirectoryRealm in Apache Shiro?

We use Apache Shiro to authenticate and authorize users using our active directory.
Authenticating the user and mapping groups works just fine using the following config:
adRealm = org.apache.shiro.realm.activedirectory.ActiveDirectoryRealm
adRealm.searchBase = "OU=MYORGANIZATION,DC=MYDOMAIN,DC=COM"
adRealm.groupRolesMap = "CN=SOMEREADGROUP":"read","CN=SOMEMODIFYGROUP":"modify","CN=SOMEADMINGROUP":"admin"
adRealm.url = ldaps://my.ad.url:636
adRealm.systemUsername= systemuser
adRealm.systemPassword= secret
adRealm.principalSuffix= #myorganization.mydomain.com
I can authenticate in Shiro using the following lines:
String user = "someuser";
String password = "somepassword";
Subject currentUser = SecurityUtils.getSubject ();
if (!currentUser.isAuthenticated ()){
UsernamePasswordToken token = new UsernamePasswordToken (user,
password);
token.setRememberMe (true);
currentUser.login (token);
}
We now want to get more user information from our ActiveDirectory. How can I do that using Apache Shiro? I was not able to find anything about it in the documentation.
In the source code of ActiveDirectoryRealm I found this line:
NamingEnumeration answer = ldapContext.search(searchBase, searchFilter, searchArguments, searchCtls);
So the first part of the answer is clear: use the ldapContext to search something in it. But how can I retrieve the LdapContext?
It depends on what you are trying to do. Are you just trying to reuse the context to run a query for something other then authentication or authorization? Or are you trying to change the behavior of the query in the AD realm?
If the latter, you would need to extend the ActiveDirectoryRealm and override the queryForAuthorizationInfo() method.
Are you implementing something that is custom for your environment?
(updated)
A couple things:
The realm has access to the LdapContext in the two touch points: queryForAuthenticationInfo() and queryForAuthorizationInfo(), so if you extend the AD realm or AbstractLdapRealm you should already have it. You could change the query to return other info and add the extra info to your Principal. Then you have access to that info directly from your Subject object.
Your realms, are not required to be singletons.
If you want to do some other sort of user management (email all users with a given role, create a user, etc). Then you could create a LdapContextFactory in your shiro.ini, and use the same instance for multiple objects.
[main]
...
ldapContextFactory = org.apache.shiro.realm.ldap.JndiLdapContextFactory
ldapContextFactory.systemUsername = foobar
ldapContextFactory.systemPassword = barfoo
adRealm = org.apache.shiro.realm.activedirectory.ActiveDirectoryRealm
adRealm.ldapContextFactory = $ldapContextFactory
...
myObject = com.biz.myco.MyObject
myObject.ldapContextFactory = $ldapContextFactory
This would work well if myObject is interacting with other Shiro components, (responding to events, etc), but less so if you need access to it from another framework. You could work around this by some sort of static initialization that builds creates the ldapContextFactory, but in my opinion, this is where the sweet spot of using the shiro.ini ends, and where using Guice or Spring shines.

AspNet Identity UserManager Find with Select (optimal sql query)

I have wcf fulRest service with AspNet Identity. My android app use this web service to communicate with database - I use ssl to make connection secure (my app is a mini game so it doesn't contain so important data, I belive that ssl is enough protection in this case).
I have function LoginUser(string userName, string unHashedPassword), if user exsists it returns user's id. In all other functions this id is used if action need information of curUser - for example I have function addComment(string userId, string msg) (this kind of methods still use ssl to protection of unwanted handle userId).
In LoginUser I get id (and a little more information like e-mail, gameLogin) by use:
using (var userManager = new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(_context)))
{
ApplicationUser user = userManager.Find(userName, password);
if (user != null)
{
result = new LogInBaseData()
{
Id = user.Id,
Email = user.Email,
Login = user.ApplicationLogin
};
}
}
But function Find generate huge query with select many unneeded data for me. Is any way to optimalizace it? I prefer do it by context.User.Where().Select() but I can't hash user's password.

Why does WCF OperationContext gets wrong WindowsIdentity

I use the below snippet of code to fetch the client user name in my WCF service. On one of my servers, I am getting the wrong client name. My client is Win7 talking to Server 2008R2 in a workgroup configuration and both machines have users Dave and Dave_Admin. Both are admin on Win7 and only the later is admin on the server. Problem is I start my client as Dave and the server shows the client as Dave_Admin. I have debugged the identities on both sides of the connection as Dave on the client and Dave_Admin on the server. The claim resources also show the Dave_Admin SID.
The only two reasons I can imagine this happens are
the server somehow finds user Dave_Admin looking for Dave which I doubt, or
after setup, I may have renamed administrative user Dave to Dave_Admin and then created a new user Dave as a standard user.
I only have a vague recollection I may have done that but am not sure if I did or not. The c:\users folder looks normal. If I did do this, and this is the reason, is there anyway to correct?
Anyone have another possible explanation or means to fix if this happens after a user rename?
OperationContext lContext = OperationContext.Current;
RemoteEndpointMessageProperty mEndpointMessageProperties = lContext.IncomingMessageProperties[RemoteEndpointMessageProperty.Name] as RemoteEndpointMessageProperty;
mIdentity = lContext.ServiceSecurityContext.WindowsIdentity;
mUserName = mIdentity.Name;
mIPAddress = mEndpointMessageProperties.Address;
mPort = mEndpointMessageProperties.Port;
mConsoleID = string.Format("IP:{0}Port:{1}", mIPAddress, mPort);
mCallbackInterface = lContext.GetCallbackChannel<IConsoleCallbacks>();
mAuthority = TxWcfServer.sSelf.Authorized(mIdentity); // get the user's authority from the WcfServer when they logged on
// show client information
if (AppSupport.IsLogLevel(LogLevel.WCF))
{
// show the various security contexts
var x = lContext.ServiceSecurityContext;
AppSupport.WriteLog(LogLevel.Note, "*** WCF WindowsIdentity is '{0}'.", x.WindowsIdentity.Name);
AppSupport.WriteLog(LogLevel.Note, "*** WCF PrimaryIdentity is '{0}'.", x.PrimaryIdentity.Name);
AppSupport.WriteLog(LogLevel.Note, "*** WCF IsAnonymous is '{0}'.", x.IsAnonymous);
foreach (ClaimSet claimset in ServiceSecurityContext.Current.AuthorizationContext.ClaimSets)
{
foreach (System.IdentityModel.Claims.Claim claim in claimset)
{
// Write out each claim type, claim value, and the right. There are two
// possible values for the right: "identity" and "possessproperty".
AppSupport.WriteLog(LogLevel.Note, "*** WCF Claim Type: {0}, Resource: {1} Right: {2}",
claim.ClaimType, claim.Resource.ToString(), claim.Right);
}
}
}
You need to turn on Impersonation on your WCF service for your code to be able to get the client context, otherwise you'll be getting the service context (Which is probably why you get Dave_Admin instead of Dave, as your service is running as Dave_Admin)
This post has information on how to turn it on:
http://msdn.microsoft.com/en-us/library/ms730088.aspx

How do I access the user's password from LDAP in a LdapUserDetailsMapper using spring security?

We are using spring security in our web application based on spring MVC.
We are doing authentication using LDAP module of spring security which is working properly. Now I need to get the user password from LDAP for saving in the database.
For this I am using this in my code.
public class PersonContextMapper implements UserDetailsContextMapper {
public UserDetails mapUserFromContext(DirContextOperations ctx, String username, Collection<GrantedAuthority> authorities) {
Person.Essence p = new Person.Essence(ctx);
p.setUsername(username);
p.setAuthorities(authorities);
Object passwordValue = ctx.getObjectAttribute("userPassword");
return p.createUserDetails();
}
public void mapUserToContext(UserDetails user, DirContextAdapter ctx) {
Assert.isInstanceOf(Person.class, user, "UserDetails must be a Person instance");
Person p = (Person) user;
p.populateContext(ctx);
}
}
But I am not getting the any value for the password. Its always null.
Please help.
PS. My authentication is successful. It means password entered in the login form is matches properly with the password stored in the LDAP.
It might be that the authentication state of the connection does not have permission to read the value of the userPassword attribute. Most often, applications issue a BIND request to the directory server, including appropriate controls as necessary. The password is included in the BIND request and the directory server changes the authentication state of the connection upon successful completion of the BIND request. In any case, the value of the userPassword attribute is encrypted or hashed more often than not, and applications have no need to read the value.