Javlog @cacek.cz

TL;DR Yes, you can add digital signatures in Java even when you use newer hardware tokens such as Gemalto SafeNet eToken 5110 CC. JSignPKCS11 might help. Maybe you've seen the infamous PKCS11 error message CKR_USER_NOT_LOGGED_IN already. Thrown even when the SunPKCS11 security provider and the keystore settings were properly configured for your hardware token. java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:685) at java.base/java.security.Signature$Delegate.engineSign(Signature.java:1404) at java.base/java.security.Signature.sign(Signature.java:713) ... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_Sign(Native Method) at jdk.crypto.cryptoki/sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:664) ...

Steps to enable Elytron in WildFly nightly builds. There is an ongoing effort to bring a new security subsystem Elytron to WildFly and JBoss EAP. For some time a custom server profile named standalone-elytron.xml  existed beside other profiles in standalone/configuration directory. It was possible to use it for playing with Elytron. The custom Elytron profile was removed now.  The Elytron subsystem is newly introduced to all standard server profiles. The thing is, the Elytron is not used by default and users have to enable it in the subsystems themselves. Let's look into how you can enable it. Get WildFly nightly build # Download WildFly nightly build wget --user=guest --password=guest https://ci.wildfly.org/httpAuth/repository/downloadAll/WF_Nightly/.lastSuccessful/artifacts.zip # unzip build artifacts zip. It contains WildFly distribution ZIP unzip artifacts.zip # get the WildFly distribution ZIP name as property WILDFLY_DIST_ZIP=$(ls wildfly-*-SNAPSHOT.zip)...

The problem If you work with virtual machines in clouds, or you run an SSH server in Docker containers, then you've probably met the following error message during making ssh connection: (I'm connecting through SSH to a docker container) ~$ ssh -p 8822 root@localhost @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:smYv5yA0n9/YrBgJMUCk5dYPWGj7bTpU40M9aFBQ72Y. Please contact your system administrator. Add correct host key in /home/jcacek/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/jcacek/.ssh/known_hosts:107 remove with: ssh-keygen -f "/home/jcacek/.ssh/know...

Sometimes the calling javax.security.auth.login.Configuration.getConfiguration() fails with SecurityException in our tests (both Oracle and IBM). A quick solution (without touching JDK installation or configuring java.security.auth.login.config system property) is simple. Just create an empty file .java.login.config in your user home directory (more info in ConfigFile JavaDoc ). Thats it! touch ~/.java.login.config Just to make the picture complete, here is the stack trace we see on IBM JDK: Exception in thread "main" java.lang.SecurityException: Unable to locate a login configuration at com.ibm.security.auth.login.ConfigFile.<init>(ConfigFile.java:125) at java.lang.J9VMInternals.newInstanceImpl(Native Method) at java.lang.Class.newInstance(Class.java:1681) at javax.security.auth.login.Configuration$2.run(Configuration.java:263) at javax.security.auth.login.Configuration$2.run(Configuration.java:255) at java.security.AccessController.doPrivileged(Acces...

If you try to find what are the security components doing in WildFly 8.x (or EAP 6.x + AS7) then enable TRACE log level for several categories. You can simply use JBoss CLI to configure it: cd $JBOSS_HOME/bin ./jboss-cli.sh -c << EOT /subsystem=logging/logger=org.jboss.security:add(level=ALL) /subsystem=logging/logger=org.jboss.as.security:add(level=ALL) /subsystem=logging/logger=org.picketbox:add(level=ALL) /subsystem=logging/logger=org.apache.catalina.authenticator:add(level=ALL) /subsystem=logging/logger=org.jboss.as.web.security:add(level=ALL) /subsystem=logging/logger=org.jboss.as.domain.management.security:add(level=ALL) /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL) quit EOT If you don't use $JBOSS_HOME environment variable, just replace it with path to your application server installation.

Chcete-li použít vlastní autorizační modul ve webové aplikaci nad JBoss AS7 (policy module v terminologii AS7 security domén), nezapomeňte přidat element use‑jboss‑authorization do konfiguračního souboru jboss-web.xml . Toť novinka oproti dřívějším verzím aplikačního serveru. Celý soubor WEB-INF/jboss-web.xml pak může vypadat například takto: <?xml version="1.0" encoding="UTF-8"?> <jboss-web> <security-domain>DomainWithCustomPolicyModule</security-domain> <use-jboss-authorization>true</use-jboss-authorization> </jboss-web> Update: Až to zase zapomenu, tak správná místa, kde hledate pomoc jsou: org.jboss.as.web.security.JBossWebRealm org.jboss.metadata.web.jboss.JBossWebMetaData and its subclasses org.jboss.metadata.parser.jbossweb.JBossWebMetaDataParser

Občas se stane, že si při práci s X509 certifikáty nevystačíte jen s možnostmi, které nabízí balík java.security.cert a rádi byste vydolovali více informací. Já jsem například řešil požadavek na získání CRL (Certificate Revocation List) souboru pro zadaný certifikát. V takovýchto případech se hodí využít kryptografickou knihovnu Bouncy Castle a pomocí ní vypreparovat třeba i střeva z vašich certifikátů. Jak tedy implementace vypadá? Nejdříve zjistíme, zda certifikát vůbec podporuje rozšíření CRLDistributionPoints a jesliže ano, máme vyhráno. Knihovna Bouncy Castle obsahuje už připravené třídy přímo pro toto rozšíření. Stačí se tedy ponořit do stromových struktur distribučních bodů a získat tak seznam URL, na kterých by měly být připraveny ke stažení CRL soubory. import java.io.IOException; import java.security.KeyStore; import java.security.cert.X509Certificate; import java.util.HashSet; import java.util.Set; import org.bouncycastle.asn1.DERString; import org.bouncycastle.asn...

Víceméně kulaté verze 0.8.0 se dočkal open source projekt JSignPdf (digitální podepisování PDF dokumentů). Hlavní změnou je přidání podpory pro dávkové zpracování, kdy je běh programu řízen argumenty příkazové řádky (bez GUI). Novou verzi stahujte zde .

Používáte-li pro správu přístupu k vaší webové aplikaci framework Acegi, možná se vám bude hodit zaznamenávat uživatelské přístupy (platné loginy) někam do databáze. Zde je jeden ze způsobů jak se s tímto problémem vypořádat. Následující přiklad používá Hibernate a databázi Oracle. Nejdříve si připravím vlastní metodu pro zápis do databáze v DAO . Umístím ji do třídy cz.mujpackage.dao.UserDao , která rozšiřuje org.springframework.orm.hibernate3.support.HibernateDaoSupport a poskytuje metody pro správu uživatelů, rolí, apod. Pro zvýšení výkonu použiji v Hibernate SQLQuery namísto vytváření instance třídy modelu a jejího ukládání pomocí metody save(...) . /** * Adds log entry to table AUTH_LOG (Oracle database form - pk_sequence has to be configured) * @param aName username * @param aRemoteAddress remote address of request */ public void logAuthenticationSuccess(final String aName, final String aRemoteAddress) { final HibernateCallback callback = new HibernateCallback() { publ...

Nedávno jsem dostal za úkol implementovat autentizaci a autorizaci (přihlašování a implementace přístupových práv) v několika webových aplikacích u zákazníka. Aplikace sice využívají Hibernate , ale bohužel už ne Spring , pro který existuje security framework Acegi , poskytující přesně tu funkcionalitu, kterou potřebujeme. Acegi už jsem v jednom projektu úspěšně použil a tak jsem nebyl nadšenej z toho, že musím hledat jiné řešení. Nakonec jsem část Acegi (zdrojáků) přeci jen použil. A to mírně upravené třídy z balíku org.acegisecurity.context , pomocí kterých lze jednoduše (s využitím servlet filtru) získat kdekoliv v aplikaci právě přihlášeného uživatele. Další krok bylo vynucení přihlášení pro přístup k chráněným částem aplikace. Přemýšlel jsem o využití možností servlet kontejneru (např. Security Realm v Tomcatu ), ale nevýhodou je, že pak pro deploy aplikace nestačí mít soubor s archivem (war), ale musíte také nakonfigurovat daný Realm přímo v instalaci Tomcatu. Navíc je toto ...

OpenOffice.org podporuje podepisování dokumentů, které jsou v jeho výchozím formátu (Open Document), ale nepodporuje digitální podpisy při exportu do PDF. Koumal jsem jak si s tím poradit a našel jsem možnost, udělat si utilitku v Javě pomocí knihovny iText . Nejlepší by asi bylo naimplementovat to přímo jako modul do OpenOffice.org, ale na to momentálně nemám čas. :-) final KeyStore ks = KeyStore.getInstance("pkcs12"); ks.load( new FileInputStream( "exported_certificate.pfx"), "cert_password".toCharArray()); final String alias = (String) ks.aliases().nextElement(); final PrivateKey key = (PrivateKey) ks.getKey(alias, "cert_password".toCharArray()); final Certificate[] chain = ks.getCertificateChain(alias); final PdfReader reader = new PdfReader("original.pdf"); final FileOutputStream fout = new FileOutputStream("signed.pdf"); final PdfStamper stp = PdfStamper.createSignature(reader, fout, '\0'); fi...