Category Archives: Domain and network services

CzechIdM Jade představuje hromadné akce a podporu SCIM 2.0

Nedlouho po představení CzechIdM 8, verze, která přinesla asynchronní správu účtů, je tu další release se spoustou nových atraktivních funkcí. Administrátory určitě potěší hromadné operace, které umožní přidělovat role více uživatelům současně. Pro snadnější integrování s jinými identity manager systémy CzechIdM nyní podporuje univerzální systém/protokol SCIM. Jednodušší integraci s moderními HR systémy zajistí podpora časových řezů v synchronizaci dat. Continue reading

IDS – Intrusion Detection System

V rámci interního vzdělávání jsem měl prezentaci o tom, co je to IDS (Instrusion Detection System) a jak jsme jej nasazovali u zákazníka. V tomto článku vám popíši základní principy IDS a jak jej správně začlenit do síťové infrastruktury. Představím vám také některé aplikace, které jsem ve svém řešení IDS použil. Na závěr se budu zabývat tím, jakým způsobem IDS nastavit, jaká volit pravidla a co použít pro vizualizaci reportů.

Continue reading

RESTful API for legacy SunSSO

For various reasons, many organizations (have to) use legacy applications. That is simply a fact we need to cope with while creating integration solutions. One of our customers use really old SunSSO, which was released about ten years ago, and use it for authenticating users. This particular version of SunSSO doesn’t have any simple API for external applications. It has only the SOAP service which cannot be used, e.g. for session token validation. Because we needed to validate sessions from other applications, we wrote ourselves a simple RESTful API.

Using servlets as REST providers

SunSSO was open-sourced in 2005 as OpenSSO but, later after acquisition, Oracle  removed the source code from the download sites. Company called ForgeRock created a fork of OpenSSO and develops the product under the name OpenAM. OpenAM comes with a nice pack of REST services. Their specification was a base specification for our servlet REST interface. The specification considered here is from OpenAM 10. In version 11, ForgeRock marked it as deprecated and moved to more convenient JSON format. Specification we used can be found here.

For accessing functionality of the access manager itself, we need to deploy servlets into the same application context. This will ensure that requests can be forwarded into the AM’s classes. The principle is that the servlet translates client requests into objects and then forwards those objects in standard manner into the access manager.

Example: Session validation

There comes a simple example on how to write a session validation servlet by yourself. First, we set up the development environment – standard J2SE project is perfectly sufficient.

Now we have to add the development dependencies: am_sdk.jar, am_services.jar, servlet.jar. All those can be found in your existing SunSSO installation. Just copy them over and update classpath of the newly created project. Also, do not forget to set appropriate JVM version (1.5 in most cases).

The validation servlet could look like this:

public class IsTokenValidServlet extends HttpServlet {

 public static final String TOKENID_GET_PARAM_NAME = "tokenid";


 public void doGet(HttpServletRequest request, HttpServletResponse response) {
 ServletOutputStream out = null;
 try {
   out = response.getOutputStream();
   String tokenid = request.getParameter(TOKENID_GET_PARAM_NAME);

   if (tokenid == null || tokenid.equals("")) {
   } else {
     SSOTokenManager manager = SSOTokenManager.getInstance();
     SSOToken token = manager.createSSOToken(tokenid);

     if (manager.isValidToken(token)) {
     } else {

 } catch (Exception e) {

Example: Servlet deployment

Suppose we created the IsTokenValidServlet as shown in the previous section. Now we need to deploy it.

First, package the compiled class into jar archive (lets call it RESTservlet.jar). Copy this jar into the directory where other SunSSO jars are located. Open the server.xml file of the AM server and add the /path/to/RESTservlet.jar into the classpath so the server can find our class.

Second, register the servlet into the AM namespace. Open the web.xml of the AM application and add those lines:

   <description>REST-like SSO token validation</description>

The final thing you need to do is to restart the application container. After the restart, you should be able to access token validation servlet in the path:



As we have shown, it is not so hard to write functioning REST-like API even for old SunSSO software but we feel that many people could actually use it. That is why we chose to make sources publicly available. You can clone the git repository from the:

We use self-signed certificate. To turn off certificate check temporarily, issue clone in the following form:

GIT_SSL_NO_VERIFY=true git clone

In the repository you can find the existing REST servlets source codes. Unfortunately – due to licensing – we couldn’t add the jar dependencies. It probably does not matter since those of you who will need to use these servlets, will probably have access to an instance of SunSSO.

Any feedback, patches or comments are greatly appreciated. If you have questions you can also contact author by email:

The new monitoring of CzechIdM system

From the moment that you could read the article about tools for monitoring our Identity Management CzechIdM, had passed quite a few months and now we made a progress. In the new version CzechIdM, which is being tested and will soon be presented to the public, there is active monitoring and sophisticated environment offers many opportunities for administrators and most simple configuration.  Let’s look what we can in the new version CzechIdM monitored and how monitoring customize to your liking.


Diagram of solutionsdiagram_en

The Admin interface

In the administration interface CzechIdM there is a new tab in the main menu called “Status Page”.



If you click on it, Czech IdM starts a set of tests and displays a table with the results.


Each line corresponds to one test:

  • The column “Type” describes the type of test, ie the information if the connection has been tested on any of the connected systems, regular starts of  synchronization, functionality of a particular user or your own code.
  • In the “Target” is the name of the test subject, in case of test connection with the connected system, is there name of the system.
  • Result” contains key information on how things turn out, whether successfully or not.
  • Time elapsed” means the time required by the test. In milliseconds.
  • Message” may contain additional information. When you find that any of the tests fared badly, here you can begin to investigate why.

Administrator therefore just one click and he knows what is OK and what isn’t. CzechIdM runs required set of controls and displays the results in a table.


Scope of of tests and their parameters can be set according to your wishes in the configuration file BCV_IdM-ear.ear/BCV_IdM-ejb.jar/META-INF/ Tests have five parameters, their names all begin with the prefix “status_”:

  • status_resources – List of connected systems, which is to be monitored connection with CzechIdM. Delimiter in the list is a semicolon, for each system you can define a time limit for the test, per colon. Use the special string “__ALL__” instead of the name of the system can determine that are to be tested all of the associated systems.
  • status_users – list of users to which the operation is “checkout-checkin”, the updating of information in CzechIdM from the source systems and the inclusion of this information in connected systems. Again, you can specify multiple users by separating them with a semicolon, again, you can set a time limit for each user.
  • status_synchronizations – list of connected systems, which should be checked for regularly starting synchronization. With each system name there is the maximum interval between synchronization runs separated by coma, different systems are separated by a semicolon.
  • status_recons – similar to status_synchronizations, instead of synchronizing is checked regularly starting reconciliations
  • status_custom_rules – tests tailored for advanced users. Can you provide a list of rules to be launched, along with every timeout and expected (error less) result.

All times are given in milliseconds.

Example configuration:

status_resources=Active Directory:10000;Docházky:5000;MySQL:5000
status_synchronizations=MySQL:3600000;Active Directory:900000

The above configuration ensures that every time you start the tests will be checked connection systems “Active Directory”, “Docházky” and “MySQL”, the success will be considered if the test for “Active Directory” ends correctly within 10 seconds, other two systems ends correctly within 5 seconds.

Plugin for Nagios

In the screenshot at the introduction you saw a table in the admin interface. For machine processing is more suited its text CSV format. It can be downloaded from the running CzechIdM from address /idm/admin/status/showcsv.seam. For regular monitoring you can use a script that comes along with the new version. Before you run it, open it for editing and set the variables at the beginning of the script according to their own use, especially login name and password. If you set run of script in cron or if you use it as part of the monitoring system Nagios, it arrives you reporting on failed test by e-mail (please check that you correctly functioning command “mail” from the shell and you do not have very strict firewall for sending mails). Please make sure to limit the rights for the script, it contains the login name and password.


CzechIdM provides for administrators a new way of active monitoring. A specific set of tests may vary on individual deployments, the administrator it can easily customize the configuration file without having to restart the application server running CzechIdM. Along with CzechIdM is also supplied control script that can serve as a plugin for Nagios. If you need help or would like some upgrades to the next version, email me at

Prezentace Metasploit framework

V rámci interních školení u nás proběhla prezentace o Metasploit framework. Metasploit framework je nástroj, který nám dokáže poskytnout velké množství informací o bezpečnostních chybách v systému. Jak už z popisu vyplývá, je známý především mezi lidmi, kteří se pohybují okolo bezpečnosti – tedy vývojáři, analytiky, hackery, atd. Jaká témata jsme v prezentaci probrali se dozvíte z agendy níže.

Continue reading

SOGo – tipy z provozu – zálohování, náprava špatně nastavených práv na kalendáře

Delší dobu používáme jako kalendářový server a webmail SOGo. Uživatelé přistupují ke kalendářům převážně z tlustého klienta – buď Thunderbird/Lightning na Linuxu a Windows nebo iCal/Callendar na Mac OS X. Během provozu SOGo jsem narazil na pár problémů znepříjemňujících život, ale postupně je autoři opravili. Nejvíc mi dal zabrat problém co jsem si způsobil sám – nefungovala práva sdílení na nově vytvořené kalendáře.

Continue reading

CzechIdM a správa poštovního serveru

Náš Identity Manager CzechIdM nasazený u zákazníků umí spravovat souborové systémy, doménové účty, firemní systémy, ale také poštovní servery. A právě správy poštovního serveru pomocí CzechIdM se bude týkat tento článek.

Co je to poštovní server?

Poštovní servery (mail servery) slouží ke zpracování elektronické pošty (e-mailů). Elektronickou poštu umí přijímat, ale také předávat dalším poštovním serverům a to převážně přes internet. V praxi kdokoliv z nás obdrží vlastní e-mailovou adresu ve tvaru cokoliv@doména.tld a přístupové heslo. Tyto přihlašovací údaje používáme pro přístup k poštovnímu klientovi – webovému rozhraní běžícímu na server (webmailu) nebo klasickému klientovi nainstalovanému na našem osobním počítači (Mozila Thunderbird, Microsoft Outlook atd.). Klient po ověření přístupových údajů a úspěšném přihlášení poté stáhne z poštovního serveru poštu a zobrazí ji. Ať už z bezpečnostních důvodů (data zůstávají na firemních serverech) nebo z organizačních důvodů si firmy často provozují své vlastní poštovní servery. S tím ale vzniká firmám nová starost – někdo se musí o e-mailové účty vytvořené na poštovním serveru starat, což administrátorům zabírá často mnoho času navíc. Jak z toho ven?


Continue reading

CzechIdM správa SAMBA domény II.

V tomto článku si ukážeme konkrétní scénáře při správě domény pomocí CzechIdM a technologie doménového řadiče SAMBA.
V minulém článku jsme nastínili, jak jednoduše je možné pomocí Identity Manageru CzechIdM spravovat doménu postavenou na Sambě. Pokud jste článek dosud nečetli, doporučuji tak nyní udělat:

Continue reading

Doménový řadič a další služby sítě – Adresářový server I

Tento článek je pokračováním k předchozím článkům (1,2), které popisují jak vybudovat Doménový řadič a další služby sítě.

Stavíme síť, která má více vzdálených poboček a chceme nabídnout uživatelům možnost přecházet z jednoho pracoviště na druhé. Abychom mu toto mohli nabídnout, je třeba, aby jeho uživatelský účet (jméno a heslo) byl dostupný napříč všemi pobočkami. Pokud k tomu přidáme ještě skutečnost, že pobočky jsou propojeny s centrálou například přes ADSL, tak nezbývá než všechny uživatelské účty uchovávat lokálně na pobočkových serverech. Pokud by tomu tak nebylo, pobočka by byla závislá na propojení s centrálou, a  každý si zřejmě dokáže představit rozladění uživatele, který přijde do práce a zjistí že se nepřihlásí, protože někdo překopl kabel od ADSL a internet prostě nejde.

Uživatelé jsou v OS Linux standardně založeni do souboru /etc/passwd, hesla mají v šifrované podobě v souboru /etc/shadow. Z hlediska doménového řadiče je jméno a heslo pouze malá část potřebných informací, další – podstatně větší množství – si Samba uchovává v lokálním souboru. Samozřejmě takto zapsané informace se velmi špatně replikují na další servery (pobočky). Continue reading