Authenticate users with LDAP server - authentication

I'm using LDAP Login Module to authenticate users with LDAP server in hybrid app. In authenticationConfig.xml I configured loginModule parameters.
<parameter name="ldapSecurityPrincipalPattern"
value="uid={username}, cn=users,dc=kadrlar,dc=uz"/>
<parameter name="ldapSearchFilterPattern"
value="(uid={username})"/>
<parameter name="ldapSearchBase"
value="dc=kadrlar,dc=uz"/>
Authentication works fine. This is one part of users.
I have some users in LDAP where I must use ldapSecurityPrincipalPattern with value="uid={username}, cn=users,dc=core,dc=kadrlar,dc=uz"/>
All other parameters are the same. This is another part of users.
How can I point the value of ldapSecurityPrincipalPattern to be able to authenticate any user from both parts of users without changing the value of ldapSecurityPrincipalPattern?

ldapSecurityPrincipalPattern is used to tell the LDAP adapter what identifying information is needed in order to successfully authenticate the user.
for example if your LDAP server was setup to use email, your pattern would be {username}#domain.com. Your question is equivalent to asking how to get the adapter to authenticate both {username}#google.com and {username}#stackoverflow.com, Which is obviously impossible since the LDAP adapter doesn't have the functionality to handle multiple attempts and the logic involved in dealing with a fail to connect and retrying using another security pattern.
A possible solution would be to set the the pattern as just {username},
and force the end user to pass in the full email address including the domain.
Similarly, in your case what you could do is set ldapSecurityPrincipalPattern to {username}, and introduce some logic in the implementation, that takes the login name from your end user,
and decide whether to set username="uid={login}, cn=users,dc=kadrlar,dc=uz"
or username="uid={login}, cn=users,dc=core,dc=kadrlar,dc=uz".

Related

User not authenticated against LDAP in Sonar 5.6

I have set the proper LDAP configuration in Sonar 5.6.6 LTS (ldap plugin v2.2.0.608) and I see in logs that the connection is established.
When I first try to login with my LDAP-login, I am able to do so, but my user has of course no permissions - that is okay.
The problem occurs, when I want to first add my user and give him i.e. sonar-administrators group. When it is set and I try to login, Sonar authenticates me not against the external system (LDAP) but uses his own data base.
I am sure it worked with Sonar 4.5 but now I cannot configure it properly.
The problem was that creation of new users adds them by default to the local database of SonarQube. To change this default behavior I found out that the REST API endpoint to create users contains the flag 'local' which defines whether the user should be considered as a local user added to the local database or he should be added as an external user authenticated again an external system like LDAP.
So final answer is to use the following REST API endpoint:
private final String CREATE_USER_API = "/api/users/create?login={login}&name={name}&local=false"
Please note the following property: local=false at the end of the string.

IBM Worklight 6.1 - connectAs endUser before authentication

I have a question about the connectAs="endUser" option, found in the adapter XML file.
In the design mode I can read
- endUser: The connection to the back end will be created with the user's identity, as authenticated by the authentication realm
So my question is: Does it have sense to use the option connectAs="endUser" without being authenticated and without defining a security test?
I am having this question, because I used to put the connectAs="endUser" in the authentication procedure
<procedure name="authenticate" connectAs="endUser"/>
Is that wrong?
So as you can see in the documentation using connectAs="endUser" is "Only valid if a user realm has been identified in the security tests for this procedure."
Here are some resources you may want to look into:
procedure element of the adapter XML file
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.dev.doc%2Fdevref%2Fr__procedure_.html&resultof%3D%2522%2563%256f%256e%256e%2565%2563%2574%2561%2573%2522%2520%2522%2563%256f%256e%256e%2565%2563%2574%2561%2522%2520
The authentication element of the HTTP adapter
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.dev.doc%2Fdevref%2Fr_the__authentication__element_o.html&resultof%3D%2522%2563%256f%256e%256e%2565%2563%2574%2561%2573%2522%2520%2522%2563%256f%256e%256e%2565%2563%2574%2561%2522%2520
Can you please provide your scenario to how you would like to use this setting in greater detail

LdapAuthenticationProvider not checking if user is not active

I can auth my website with either ldap or by looking in db using different spring security authentication providers.
When i use the database auth, i use UserDetailsService, which correctly checks if my user is notActive and throws DisabledException correctly.
but using LdapAuthenticationProvider this does not occur. why?
spring security 2.0.1
Which LdapAuthenticator are you using? If you use BindAuthenticator it will bind as the given user, eventually the directory server should reject if the user account disabled/expired.
I haven't used LdapAuthenticationProvider myself, but if its not done automatically you can retrieve the userdetails, The UserDetails class has bunch of methods to check weather the account is enabled/locked/expired.

CAS authentication and limiting access for specified users

I'm using CAS (Central Authentication Service) from Jasig in a client JSF app running on tomcat 6 server. I would like to limit the access to the app just for the users specified in my database rather than all the users which can be authenticated using that CAS service. When the user attempts to log in, I need to check if his username is also in my database's table user and if it is - allow the access to the app. Otherwise, I would like to redirect user to a page "You don't have permission to access this part of the application". So I need authorization as well. Is there a good way to authorize the users in jsf 2.0? Thanks in advance for any help/suggestions.
Sounds like you need to design a custom Authentication Handler class in CAS. In theory, your handler would extend this [1], perform all the necessary checks and database look ups and will then be able to return a signal that indicates whether or not the user could authN.
You should then reference your custom handler in the deploerConfigContext.xml file.
For displaying the message, you could either throw an exception with the proper messages code, such that the message would appear above the login form, or you could alter the spring webflow and generate a new view-state which the user would be redirected to, if they fail to get access. The first approach is much easier to implement.
Another approach would be to take advantage of the isUserInRole() method [2] using the persondir api.
[1] http://developer.jasig.org/projects/cas/cas-server-core/cas-server/cas-server-core/apidocs/org/jasig/cas/authentication/handler/support/AbstractUsernamePasswordAuthenticationHandler.html
[2] https://wiki.jasig.org/pages/viewpage.action?pageId=47874068

Integrated Authentication on Webserver - Security?

We have our own web server hosting our website that is open to the public outside of our network.
I have a request to make our "Internal Postings" link on our Careers page to authenticate the user against our network's Active Directory list.
I currently have it setup so the link hits a page inside the directory structure of the website, and this page's folder is set to "Integrated Windows Authentication". Anonymous access is turned off for this page. If the user is authenticated (ie: logged into our network or supplies proper credentials) it passes them on to an external careers website which hosts our job postings. If they fail to authenticate, it displays a custom 401 error page.
This works fine, but there is a problem with it. Using IE, people cannot just enter their username. They (of course) are required to enter the domain name as well. Unfortunately the default 'domain' is set to the URL of our website (www.xyz.com/username). I would like it to automatically choose the name of our internal domain (aaa/username) but am unsure of how to do this.
Another option would be to use LDAP and a little ASP scripting to authenticate the user. I have this code already, but am unsure of the security consequences of doing so. Basically, the page will be setup for anonymous authentication, and if the user isn't logged into our network, they will be prompted for a username/password using standard textboxes. This is then passed to an ASP script that does an LDAP lookup against our Active Directory. Is there any security issues with this method?
Which method would you choose to do?
Thanks.
EDIT: It seems I cannot authenticate to ActiveD via LDAP using a username/password combo. So forget about that option.
My question now is, how can I change the default 'domain' that IWA uses? Is that at all possible? IE seems to default to 'www.xyz.com\username' (my website) rather than 'aaa\username' (my domain name). Of course, www.xyz.com\username fails because that is not where our ActiveD resides... Is this possible? I want to make it as simple as possible for our employees.
You cannot authenticate an user with a script that looks up the user in LDAP. You need to know that the user is who it claims it is, and the only way to do that is to let NTLM/Kerberos authenticate the user (ie. establish proof that the user knows a secret stored in the AD, the password).
The URL of the web site to the set of sites considered be in the local intranet zone for IE browsers running on the internal network. By default sites consider to local intranet will be sent the current logged on users credentials when challanged with NTLM/Kerberos. Hence your internal users shouldn't even see a network logon box.
I hate to dredge up an old thread, but the answers are a bit misleading, if I understand the question. The thread Remus refers to is about authenticating via LDAP with a username only. As he points out, that isn't possible. But it looks like what Kolten has in mind is authenticating via LDAP with a username and password both. That's a standard practice called binding.