For bypassing using socks proxy use following command :
mvn install -DproxySet=true -Dsocks.proxyHost=YOU_SOCKS_PROXY_ADDRESS -Dsocks.proxyPort=SOCKS_PROXY_PORT
This command works in Linux and Windows
Happy coding.
For bypassing using socks proxy use following command :
mvn install -DproxySet=true -Dsocks.proxyHost=YOU_SOCKS_PROXY_ADDRESS -Dsocks.proxyPort=SOCKS_PROXY_PORT
This command works in Linux and Windows
Happy coding.
If you are working in an enterprise infrastructures, chances are that you are using a centralized authentication system, most likely Active Directory or openLDAP. In this blog I’ll explore how to create a REST API using spring boot to authenticate against openLDAP and create a JWT token in return.
Before getting our hand dirty, we need to review the architecture of spring security and the way we want to utilise it, in a REST API endpoint. According to openLDAP, I’ve explained it’s concept briefly before, you can read more about it here. Also I’ll assume that you know how Spring Boot and JWT works.
Spring Security
In this example I will extend the WebSecurityConfigurerAdapter. This class will assist me to intercept security chain of spring security and insert openLDAP authentication adapter in between.
In fact this abstract class provides convenient methods for configuring spring security configuration using HTTPSecurity object.
First of all I injected three different beans as follows :
private OpenLdapAuthenticationProvider openLdapAuthenticationProvider; private JwtAuthenticationEntryPoint jwtAuthenticationEntryPoint; private JwtRequestFilter jwtRequestFilter;
Then override the configure(AuthenticationManagerBuilder auth) :
@Override protected void configure(AuthenticationManagerBuilder auth) throws Exception { auth.authenticationProvider(openLdapAuthenticationProvider); }
This will let us to override default behaviour of spring security authentication. In addition we need to override the configure(HttpSecurity httpSecurity):
@Override protected void configure(HttpSecurity httpSecurity) throws Exception { // We don't need CSRF for this example httpSecurity .csrf().disable() .headers() .frameOptions() .deny() .and() // dont authenticate this particular request .authorizeRequests().antMatchers("/api/login").permitAll(). // all other requests need to be authenticated antMatchers("/api/**").authenticated().and(). // make sure we use stateless session; session won't be used to // store user's state. exceptionHandling().authenticationEntryPoint(jwtAuthenticationEntryPoint).and().sessionManagement() .sessionCreationPolicy(SessionCreationPolicy.STATELESS); // Add a filter to validate the tokens with every request httpSecurity.addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter.class); }
Also For the sake of manually authenticating a user in /api/login we will expose the authenticationManagerBean() :
@Bean @Override public AuthenticationManager authenticationManagerBean() throws Exception { return super.authenticationManagerBean(); }
After configuring WebSecurityConfig, I’ll provide my customer authentication adapter. This adapter will utilise spring’s LdapTemplate and let us to establish a connection to a LDAP server.
@Component public class OpenLdapAuthenticationProvider implements AuthenticationProvider { @Autowired private LdapContextSource contextSource; private LdapTemplate ldapTemplate; @PostConstruct private void initContext() { contextSource.setUrl("ldap://1.1.1.1:389/ou=users,dc=www,dc=devcrutch,dc=com"); // I use anonymous binding so, no need to provide bind user/pass contextSource.setAnonymousReadOnly(true); contextSource.setUserDn("ou=users,"); contextSource.afterPropertiesSet(); ldapTemplate = new LdapTemplate(contextSource); } @Override public Authentication authenticate(Authentication authentication) throws AuthenticationException { Filter filter = new EqualsFilter("uid", authentication.getName()); Boolean authenticate = ldapTemplate.authenticate(LdapUtils.emptyLdapName(), filter.encode(), authentication.getCredentials().toString()); if (authenticate) { List<GrantedAuthority> grantedAuthorities = new ArrayList<>(); grantedAuthorities.add(new SimpleGrantedAuthority("ROLE_USER")); UserDetails userDetails = new User(authentication.getName() ,authentication.getCredentials().toString() ,grantedAuthorities); Authentication auth = new UsernamePasswordAuthenticationToken(userDetails, authentication.getCredentials().toString() , grantedAuthorities); return auth; } else { return null; } } @Override public boolean supports(Class<?> authentication) { return authentication.equals(UsernamePasswordAuthenticationToken.class); } }
Another part that we have to take into consideration is, implementing user login controller. Since we haven’t provided any filter for controlling username and password we ought to implementing it manually as follows :
@RestController @RequestMapping("/api/login") public class LoginController { @Autowired private AuthenticationManager authenticationManager; @Autowired private JwtTokenUtil jwtTokenUtil; @Autowired private UserService userService; @PostMapping public ResponseEntity<?> createAuthenticationToken(@RequestBody JwtRequest authenticationRequest) throws Exception { authenticate(authenticationRequest.getUsername(), authenticationRequest.getPassword()); final User userDetails = userService.loadUserByUsername(authenticationRequest.getUsername()); final String token = jwtTokenUtil.generateToken(userDetails); return ResponseEntity.ok(new JwtResponse(token)); } private void authenticate(String username, String password) throws Exception { try { authenticationManager.authenticate(new UsernamePasswordAuthenticationToken(username, password)); } catch (DisabledException e) { throw new Exception("USER_DISABLED", e); } catch (BadCredentialsException e) { throw new Exception("INVALID_CREDENTIALS", e); } } }
These are the pillars of having a REST API + JWT + LDAP back-end using spring boot.
Now we can test the API using a REST client.
After getting the JWT token we can call authorized endpoints
You can find a working source code on my github.
For the next part I’ll make this code more concise.
In fact you can’t do it without knowing DN! There is an anonymous access in openLDAP which is enabled by default. The anonymous access let one to query(search filter) openLDAP without knowing bind username/password.
Run following command on your openLDAP server :
ldapwhoami -H ldap:// -x
If you get “anonymous” as result you are all set and your openLDAP is supporting anonymous query, otherwise this blog is not the one you are looking for!
Assume you know UID of the user in ldap directory but not his DN and assume the root directory hierarchy is : dc=devcrutch,dc=com . How do you want to get CN and then DN of such user in LDAP just by using UID? you might think of such query to get data out of openLDAP
uid=USERNAME,dc=devcrutch,dc=com
If you run this query, it’ll get you to nowhere.
First of all you have to query the whole directory for finding such user. You have to create a query similar to following:
(&(objectClass=*)(uid=USERNAME))
This query will search the entire Directory Information Tree (DIT) for such user name.
ldapsearch -x -h 127.0.0.1 -b dc=devcrutch,dc=com "(&(objectClass=*)(uid=USERNAME))"
With such query you can get the DN. Using DN and password you can authenticate against LDAP.
Well this was the idea, applying a search filter using USERNAME via anonymous identity then find the DN and finally login using the retrieved DN.
Now we have the rough idea it’s time to implement it in java. For finding DN you need to query the entire LDAP directory (note: in real world searching the entire directory is not a good idea, you have to narrow your query, otherwise your query might consume all the server’s resources)
private String findDN(String user) throws Exception { DirContext ctx = getContext(); String dn = null; String filter = "(&(objectClass=*)(uid=" + user + "))"; NamingEnumeration answer = ctx.search("", filter, getSimpleSearchControls()); if (answer.hasMore()) { SearchResult result = (SearchResult) answer.next(); dn = result.getNameInNamespace(); } answer.close(); return dn; }
Then after finding the correct DN you can bind your username and password
public DirContext bind(String username, String password) throws Exception { DirContext dirContext; Hashtable<String, String> env = new Hashtable<String, String>(); String dn = findDN(username); env.put(Context.SECURITY_AUTHENTICATION, "simple"); env.put(Context.SECURITY_PRINCIPAL, dn); env.put(Context.SECURITY_CREDENTIALS, password); try { dirContext = getContext(env); } catch (javax.naming.AuthenticationException e) { throw new Exception(e); } return dirContext; }
That’s it.
You can find a working source code on my github
In Spring Boot there is an annotation @Async to assist developers for developing concurrent applications. But using this feature is quite tricky. In this blog we will see how to use this feature along with CompletableFuture. I assumed you know the drill about CompletableFuture, so I won’t repeat the concept here.
First of all you need to annotate your application class with @EnableAsync, this annotation tells the Spring to look for methods that are annotated with @Async and run them in a separate executor.
@SpringBootApplication @EnableAsync public class App { RestTemplate public static void main(String[] args) { SpringApplication.run(App.class, args); } }
If you take a look at Spring Boot example about @Async using CompletableFuture you’ll notice the way they’re using this feature is based on a REST request, in my opinion, I beleive, it’s kinda limited, it doesn’t give you a clue of how to use such feature in other situation. For an instance if you have a long running task what would you do about it?
// Source : https://spring.io/guides/gs/async-method/ package hello; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.boot.web.client.RestTemplateBuilder; import org.springframework.scheduling.annotation.Async; import org.springframework.stereotype.Service; import org.springframework.web.client.RestTemplate; import java.util.concurrent.CompletableFuture; @Service public class GitHubLookupService { private static final Logger logger = LoggerFactory.getLogger(GitHubLookupService.class); private final RestTemplate restTemplate; public GitHubLookupService(RestTemplateBuilder restTemplateBuilder) { this.restTemplate = restTemplateBuilder.build(); } @Async public CompletableFuture<User> findUser(String user) throws InterruptedException { logger.info("Looking up " + user); String url = String.format("https://api.github.com/users/%s", user); User results = restTemplate.getForObject(url, User.class); // Artificial delay of 1s for demonstration purposes Thread.sleep(1000L); return CompletableFuture.completedFuture(results); } }
In FindUser(String user), it uses a synthetic delay in the main thread also the main task of this method is fetching data from github using RestTemplate, this class is a “Synchronous client to perform HTTP requests”. How about using a long running task such as calling a network function, like ping a server from your REST endpoint? In that case you need to tailor the CompletableFuture. You can’t simply call following line and carry on.
return CompletableFuture.completedFuture(results);
For using @Async in your code, your method has to return Future or CompletableFuture for more information you can refer to its document. Take a look at following example :
@Async public CompletableFuture<Boolean> isServerAlive(String ip) { CompletableFuture<Boolean> future = new CompletableFuture<Boolean>(){ @Override public Boolean get() throws InterruptedException, ExecutionException { InetAddress address = null; try { address = InetAddress.getByName(ip); return address.isReachable(1000); } catch (UnknownHostException e) { e.printStackTrace(); return false; } catch (IOException e) { e.printStackTrace(); return false; } } }; return future; }
In this example I override the get() method and return the CompletableFuture without any thread executor, in fact with this method we ask Spring to execute the @Async method in a different thread, but we don’t provide any thread executor, only body of a background-worker will suffice.
download source code from github
P.S : In this example I decided to use a network function inside Spring Boot just for the sake of argument. But it’s better to not to use network functions directly in a REST endpoint. Specially when you expect to get an immediate result out of it. The reason: network functions are blocking which means, if you call this REST endpoint. You’ll have to wait to get the result from the endpoint. It’s highly advised to use other methods such as queue or push method(e.g. websocket) for calling blocking functions.
OpenLDAP installation is fairly straight-forward and doesn’t have any caveats, but making it replicable has ambiguity. We will start with installing openLDAP. I will use following configs :
Installing openLDAP :
First thing first, update your ubuntu box :
sudo apt-get update
Install openLDAP :
sudo apt-get install slapd ldap-utils
During installation process you will prompted to enter administrator password. After installing the ldap server you need to configure it :
sudo dpkg-reconfigure slapd
You will see a basic gui with couple of prompts of how to configuring your openLDAP here is my config:
That’s it, if you ever want to check status of your openLDAP :
ldapwhoami -H ldap:// -W -D "cn=admin,dc=lab,dc=devcrutch,dc=com"
This command will prompt you to enter your password and if you enter it correctly you will get following response :
dn:cn=admin,dc=lab,dc=devcrutch,dc=com
You are all set to use openLDAP. Now let’s add an user for replication purposes inside provider (master) node. The replication user only needs to have a password and an OU, run following commands to add repl user with only a password
dn: cn=repl,dc=lab,dc=devcrutch,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: repl userPassword: {SSHA}Px1UjD+3EMII0g+JZBdZkdO6lhZt4j4k #password is abc123
Save the above file in an LDIF file and run following command. I will call this file add_repl.ldif
ldapadd -Y EXTERNAL -H ldapi:// -f add_repl.ldif
This user needs to have a privilege to only read couple of items from directory, the most important items to read, is userPassword, cn, uid and shadowLastChange. But before granting such access there is an issue with openLDAP’s configs that shipped by Ubuntu 16.04. It is best to remove those configs using following command :
#Run ldapsearch -Y EXTERNAL -H ldapi:// -b "cn=config" #Not approapriate configs for making your openLDAP replicable olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read
For deleting them run:
ldapmodify -Y EXTERNAL -H ldapi://
In the prompt write following lines one by one (this way you will delete them step by step for the sake of not getting any error)
dn: olcDatabase={1}mdb,cn=config changetype: modify delete: olcAccess olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none #press enter dn: olcDatabase={1}mdb,cn=config changetype: modify delete: olcAccess olcAccess: {0}to attrs=shadowLastChange by self write by * read #press enter dn: olcDatabase={1}mdb,cn=config changetype: modify delete: olcAccess olcAccess: {0}to * by * read #Press ctrl-d at the end
And add following configs :
#Execute ldapmodify -Y EXTERNAL -H ldapi:// #Then write these configs in it, at end press ctrl-d dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=lab,dc=devcrutch,dc=com" write by dn="cn=repl,dc=lab,dc=devcrutch,dc=com" read by * none #press enter dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcAccess olcAccess: {1}to dn.base="" by * read #press enter dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcAccess olcAccess: {2}to * by self write by dn="cn=admin,dc=lab,dc=devcrutch,dc=com" write by * read
Now your provider is ready. We will go to consumer server. First of all install openLDAP using mentioned configs, it should be the same as the master. At the end add following configs into your consumer’s openLDAP :
#run ldapmodify -Y EXTERNAL -H ldapi:// dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID eq #press enter dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryCSN eq #press enter dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: ou eq #press enter dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: uid eq #press enter dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: cn eq #press enter dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: dc eq #press enter dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=001 provider="ldap://YOUR_MASTER_IP_ADDRESS:389/" type=refreshAndPersist retry="60 30 300 +" searchbase="dc=lab,dc=devcrutch,dc=com" bindmethod=simple binddn="cn=repl,dc=lab,dc=devcrutch,dc=com" credentials="abc123"
The reason I separate configs is because of stupidity level of ldap tools. If you happen to have one of these configs inside your openLDAP previously, the ldapmodify nags about it and will kick you out without knowing which config is saved and which one isn’t, so the best way for me was saving them sequentially.
Reason for having another user rather the “cn=admin” was because of security, if you take a closer look at the latter config you will see that you have to add your password as a plain text. So it’s best to not to reveal your admin’s password. The repl user is a readonly user.
At the end you can install phpOpenLDAP in provider and consumer :
sudo apt-get install phpldapadmin
Edit below config :
sudo vim /etc/phpldapadmin/config.php
Change the following :
Find the line contains
$servers->setValue('server','base',array('dc=example,dc=com'));
Change it to
$servers->setValue('server','base',array('dc=lab,dc=devcrutch,dc=com'));
And another line contains
$servers->setValue('login','bind_id','cn=example,dc=com');
Change it to
$servers->setValue('login','bind_id','cn=admin,dc=lab,dc=devcrutch,dc=com');
Note: In this tutorial I’ve tried to create a replication server, replication doesn’t mean you have availability, which means if your master(provider) server is down then your client querys the slave(consumer) server. Replication means consistency not availability. If you happen to want availability you need to config openLDAP in multi-master mode.
Iptables is a software firewall based on Netfilter, in fact it’s a framework for working with Netfilter. Generally firewalls have two modes, stateless and stateful. In this post we will study a brief of how to configure Netfilter in stateful mode.
I’m going to assume your linux box is fresh installation and doesn’t have any rules on it. You can check your iptables rules by typing following command :
sudo iptables -nvL -t filter
Breakdown:
-L : Shows list of rules
-t filter : t stands for table. The table we want to work with is calling filter, eventhough it’s the default table but I’d rather to mention it
-n : Avoid long reserve DNS and only shows IP addresses
-v : Verbose
Next write following commands :
sudo iptables -A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A INPUT -p tcp -m state --state NEW -j ACCEPT
Rule of Thumb: The order of writing rules matters. You have to take take into account that Netfilter’s rules are checked sequentially and route of a packet is determined on the first match.
The first rule says if the packet is ESTABLISHED or is RELATED to another packet(e.g. ICMP error messages) then it can pass through. If the packet is completely NEW to Netfilter, it skips the first rule and try to match the packet with the second rule. Since ESTABLISHED and RELATED are more frequent, this helps iptables to perform faster by reducing number of rules to check.
Reason: When a client sends a packet to a server, it actually sends a SYN to server. Client’s packet enters into NEW state in Netfilter.
Then server sends a SYN+ACK back to the client, and now it’s client turn to send ACK to the server again. The client is in ESTABLISHED state after sending the ACK.
BreakDown:
-A : Append the rule to following chain, in this case INPUT chain
-p : Protocol (In this case TCP)
-m : Which module we want to use. For making Netfilter stateful we will use state module
–state : Identify the state of packet. This argument comes after the -m state
-j : What action Netfilter has to do with the packet ACCEPT / DROP or REJECT
Note: module state is deprecated and you can use conntack module instead, but according to this post state module is valid yet and no need to be worry about it.
In this post I dived into Netfilter stateful packet filtering and tried to reason why ones need to write rules in such order, of course there are so many stones remained unturned. Hopefully I will write more about Iptables/Netfilter.
Let’s say you have a central authentication server in a LDAP and you successfully connect your Linux box as a client to LDAP server. Whenever you are using a particular LDAP user to login to your box, your shell get confused and change the LDAP user with a local user of your box intermittently. What is the problem?
for making it crystal clear lets say your local user ID is : 1000 for knowing the id of user in Ubuntu you can run following command :
id
And this will print out uid, gid and the group id of the user.
Now if you go to your LDAP server and query the same user name you will notice that his LDAP’s uid is also the same as the local user id 1000.
for solving this problem you either have to change local uid or LDAP uid.
This is a common symptom of mis behaviour of systemd-logind. I couldn’t still find-out what is really happening underneath of this service but if you experience such issues you can try to restart the service using following command
sudo service systemd-logind restart
and make sure to run this code on the console not just by using ssh.
If anyone knows more about underlying components of systemd-logind please give me some more information about it.
For installing Maven on Ubuntu you have two ways the easy way and the manual method. The easy way is just execute following command :
sudo apt-get install maven
Or if you use Ubuntu 16+ you can use following command too :
sudo apt install maven
Just remember you need to have root privileges.
If you want to have the latest version of Maven on your Ubuntu go to the Maven website and download the latest binary package then you can extract it in /opt/ using command :
tar xvf apache-maven-3.5.2-bin.tar.gz -C /opt/
make sure you have set your JAVA_HOME if you don’t know how you can read this post
then open up your /etc/environment add following to your path
PATH=_YOUR_OLD_PATH:/opt/apache-maven-3.5.2/bin/
quit from your editor then type
source /etc/environment
to test if maven is installed type
mvn -v
There are sometimes that you want to trace an IP/Host based on a particular port to check if the port is open or not here is how you can do that :
traceroute -T -p 25 yoursite.com
Breakdown :