Ricky's Hodgepodge

Sometimes I think that the DNIe situation is just recurring, I feel like Bill Murray in the film Groundhog Day. During the last years the Spanish electronic ID (DNIe) has been working good inside the OpenSC project (since the DNIe v3.0 was integrated around 2017). I personally had not received any report of problems with it. But it happens that my personal card expired in august (the previous renewal was because the chip stopped working and the expiration date was not extended that time). I went to the police station and, after coming back home, my fresh new smartcard was not working with OpenSC. Again. The worst thing was that the official RPM package for linux distributed by the government failed with my card too.

Looking into the issue inside the OpenSC code, the initial problem was that a certificate that is used to establish the secure channel (secure communication with the card, similar to what https is to http) failed when it was validated. The certificate for the intermediate CA is placed in the card itself and, in order to validate that the certificate was not altered, it is verified against a public key (the public key of the CA that is issuing those certificates for the Spanish ID cards). That key (among other things needed for the secure channel like some certificates, other public and private keys, key references inside the card,...) is just hardcoded inside the code. Therefore that verification failure only meant that the Spanish Police Department (DGP) had changed that CA. The first thing I tried was just commenting that verification, but the secure channel creation failed in a later step. So it was crystal clear that all the CA structure that is needed for the secure channel had been replaced. I searched over the internet for the data. Previously that information was published by the Spanish institutions inside the sources of some public projects, like for example jmulticard or inside the FNMT MultiPKCS11 sources (code for the official PKCS11 package, the zip file can be downloaded at the end of page). But nothing, I found absolutely nothing, only the previous data was there, the one that now failed with my new card.

The official code stores the configuration in ASN.1 format inside a fixed global byte array variable. So doing some readelf/objdump magic over the binary library I got the full bytes and started a slow and manual parsing. I detected that there were two configurations there. I was very skeptical about this, in the end the official package was not working for me either, but why were there two configurations? I continued parsing the ASN.1 and obtained the modulus for the public key whose verification was failing from both confs. One was the same value used in the current OpenSC code but the other key was a different array. So I backed up the certificate from the card (the one being validated) and created a simple program to verify it with the new key found in the second configuration. And surprisingly it worked. It was the valid public key whose private counterpart signed the intermediate CA certificate in the card. That convinced me to finish the whole parsing and replace all the data for the secure channel creation with this new one. In two days I could finish the task and OpenSC was working again with my new DNIe. At least changing the data to establish the secure channel was enough, no more changes were needed.

More or less at that point I was notified that there were some issues reported in the OpenSC project about new DNIe cards not working. The main one is the issue 2105 and I started to share what I had at that moment. The final conclusion is that if you have a DNI with IDESP equals or greater than BMP100001 the new CA structure is used and current OpenSC does not work with it. The command dnie-tool -i displays the IDESP information for your card. A PR was sent to the project to manage both configurations (the old data should be maintained for previous cards) and it seems to be working for testers. Let's see if the maintainers accept it promptly.

In summary, if you have a new DNIe card and you want to use OpenSC to access with it some governmental sites, it will not work for you. The situation is the same with the official package. Only windows distribution seems to be working at this moment. If you are in a hurry you can try out the PR and compile it by yourself. As a personal comment I am going to say that maintaining the DNIe inside OpenSC this way is really complicated. The DGP (Spanish institution in charge of the DNIe) continues doing the things in linux utterly in the wrong direction. This time I was lucky and, first, I renewed my DNIe at the perfect time to discover the issue and, second, finding the new data in the binary distribution was just a long shot. In a normal situation this would have meant waiting for the publication of the new data (direct DPG announcement or some code added to the previously mentioned projects) and trying to fix it without a new card, waiting for the community for the testing. As always, remember that I am not related at all with the DGP or the FNMT. I am just a frustrated linux user who needed to use the DNIe some time ago. And I am starting to be really tired with all this.

Regards!

Unexpectedly I am going to write a continuation of the previous entry about JASPI. The past week I needed to work with the new Java EE Security API Specification (JSR 375) and, because it is based on JASPI, the new specification is somewhat related to the previous post. There are several good articles over the internet about the new javaee security framework, for example Jakarta EE 8 Security API by baeldung or the overview done by DZone. Today's entry is just going to use the JSR 375 specification with a Wildfly 19 server.

Following the previous guides about the new API, a little sample application is going to be developed. The framework lets you configure the application login just defining a ApplicationScoped bean. The bean defines the authentication mechanism and the storage to use.

package es.rickyepoderi;

import javax.enterprise.context.ApplicationScoped;
import javax.security.enterprise.authentication.mechanism.http.FormAuthenticationMechanismDefinition;
import javax.security.enterprise.authentication.mechanism.http.LoginToContinue;
import javax.security.enterprise.identitystore.LdapIdentityStoreDefinition;

@FormAuthenticationMechanismDefinition(loginToContinue = @LoginToContinue(
        loginPage = "/login.html",
        errorPage = "/login-error.html"
))
@LdapIdentityStoreDefinition(
    url="ldap://localhost:1389",
    bindDn="cn=Directory Manager",
    bindDnPassword="XXXX",
    callerSearchBase="ou=People,dc=sample,dc=com",
    groupSearchBase="ou=Groups,dc=sample,dc=com",
    groupNameAttribute="cn",
    groupMemberAttribute="uniqueMember"
)
@ApplicationScoped
public class ApplicationConfig {
}

So the application is going to use a FORM login (an HTML page will be shown to the user to login) and the user info are going to be retrieved from an LDAP server. The API gives more options for the mechanism (BasicAuthenticationMechanismDefinition and CustomFormAuthenticationMechanismDefinition) and the storage (DatabaseIdentityStoreDefinition or a custom IdentityStore). With the bean done, a HelloServlet is introduced.

package es.rickyepoderi;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.annotation.HttpConstraint;
import javax.servlet.annotation.ServletSecurity;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet({"/hello"})
@ServletSecurity(@HttpConstraint(rolesAllowed={"static-group1"}))
public class HelloWorldServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try (PrintWriter writer = response.getWriter()) {
            response.setContentType("text/plain;charset=UTF-8");
            writer.append("Hello ")
                    .append(request.getUserPrincipal() == null? "World" : request.getUserPrincipal().getName())
                    .append("!");
        }
    }
}

The Servlet is annotated to request a role (static-group1) which will be a group of the user in the LDAP repository. In my humble opinion the security API needs to be extended to apply these constraints in other places, right now only servlets can be annotated and, if I am not wrong, this is quite short (why not annotate other generic URLs that can be JSP, JSF, jax-rs,...). Adding a general place (in the bean for example?) to include constraints for generic URLs would be awesome. I have to say that I am still surprised about this, if I missed something please add a comment in the bottom section.

The final step when using wildfly is defining the jaspitest security domain. Why? Because the JSR 375 works with JASPI and, therefore, the application should be configured to use a JASPI capable security domain. The default security domain other configured by wildfly is not JASPI. In a common application the jboss-web.xml should be placed setting the module to use.

<jboss-web>
    <security-domain>jaspitest</security-domain>
</jboss-web>

And that is all. The application should work in wildfly 19 for example. Just download, install it and deploy the application. You can download the maven project for the sample app from here.

wget https://download.jboss.org/wildfly/19.0.0.Final/wildfly-19.0.0.Final.zip
unzip wildfly-19.0.0.Final.zip
cd wildfly-19.0.0.Final/bin
./add-user.sh -u admin -p XXXX
./standalone.sh
./jboss-cli.sh --connect
deploy /path/to/javaee8sec/target/javaee8sec.war

But what if I do not want to specify the jboss-web.xml in the application, in the end this is not part of the standard. Well, the solution is quite simple, you can just change the default security domain for the web/undertow to jaspitest.

./jboss-cli.sh --connect
/subsystem=undertow:write-attribute(name=default-security-domain, value=jaspitest)
/:reload

The application now will work without the jboss-web.xml, because the jaspitest security domain is used by default by the apps that do not specify one. But what happens with elytron, in the previous entry we saw that the new security subsystem supports JASPI too, so, how can we configure the server to use it instead of the old security domain? Just like it was shown in the old entry, an undertow/elytron domain should be configured with JASPI enabled but not integrated. Here it is an example to configure elytron globally and enable JASPI for the security API.

cd wildfly-19.0.0.Final
bin/jboss-cli.sh --file=docs/examples/enable-elytron.cli
cd bin
./standalone.sh
./jboss-cli.sh --connect
/subsystem=undertow/application-security-domain=other:write-attribute(name=integrated-jaspi, value=false)
/subsystem=undertow:write-attribute(name=default-security-domain, value=other)
/:reload

The provided enable-elytron.cli is first used to completely configure elytron security (now everything in wildfly uses elytron instead of the old security system). Finally the default other domain is changed to set integrated-jaspi to false. Remember that this property makes that JASPI alone is enough to authenticate users, if false the user is also located in the associated realm inside elytron and for the security API that needs to be avoided.

As a summary wildfly 19 is JavaEE 8 certified and, therefore, the new security API is available. In the entry a little sample application was deployed to authenticate users against an LDAP server. The final points were used to avoid the inclusion of the jboss-web.xml in the application and configure the server to automatically use a domain that is JASPI enabled, using both, the old jaspitest domain and the new elytron susbsystem.

Best regards!

Today's entry is dedicated to Java Authentication Service Provider Interface for Containers (JASPIC or just JASPI) in the wildfly server. Since version 15 the new elytron security provider allows JASPI configuration for applications. This post is going to explain how to move from the old security configuration (which also provided JASPI) to the new one.

JASPI or JASPIC is a standard JavaEE API to authenticate users into the container. In general a ServerAuthModule should be implemented and the method validateRequest gets the user data from the request and validates it against the users and roles repository (LDAP, database,...). For the entry I am going to use a silly example. My module is just a BASIC authentication, it reads the header Authorization to retrieve the username and password, and validates the data against a pre-configured list of users. In JASPI the initialize method receives a map of options, and that map will be used to pass the list of usernames, passwords and roles managed by my sample. Each map entry will have the following format:

"username" => "password[###role1,role2,...]"

It is just a toy module but enough to exemplify how to use it in the old and the new security system. Here you can download the jaspi-module maven project which generates the final library (jaspi-module-1.0.jar). Let's start the configuration in wildfly 18.

1. The first step is adding the module into the server.

   
   module add --name=es.rickyepoderi.jaspi --resources=/path/to/jaspi-module-1.0.jar --dependencies=javax.servlet.api,javax.security.auth.message.api
   

2. Now configure the JASPI in a security domain.

   
   /subsystem=security/security-domain=jaspi-module:add
   /subsystem=security/security-domain=jaspi-module/authentication=jaspi:add(auth-modules=[{code=es.rickyepoderi.jaspi.ExampleServerAuthModule, module=es.rickyepoderi.jaspi, flag=required, module-options={"user1" => "password1###user,role1", "user2" => "password2###user", "user3" => "password3"}}])
   

   The security domain called jaspi-module adds my ServerAuthModule and initializes it with three users (user1, user2 and user3), and the first two are assigned to the role user while the third one is not.

3. Now it is the time to deploy an application. A hello-world-jaxrs app was developed that is just a hello world but secured with the previous module. The hello endpoint says hello to the logged user. For that, the standard web.xml is used.

   
   <?xml version="1.0" encoding="UTF-8"?>
   <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
            version="3.1">
   
       <security-constraint>
           <web-resource-collection>
               <web-resource-name>All resources</web-resource-name>
               <description>Protects all resources</description>
               <url-pattern>/*</url-pattern>
           </web-resource-collection>
           <auth-constraint>
               <role-name>user</role-name>
           </auth-constraint>
           <user-data-constraint>
               <transport-guarantee>NONE</transport-guarantee>
           </user-data-constraint>
       </security-constraint>
   
       <security-role>
           <description>Role required to log in to the Application</description>
           <role-name>user</role-name>
       </security-role>
   
       <login-config>
           <auth-method>BASIC</auth-method>
       </login-config>
   </web-app>
   

   All the pages are protected and requires the user role (the one assigned to the first two users but not to user3). And finally the custom jboss-web.xml uses the jaspi-module security domain configured in the previous point.

   
   <jboss-web>
      <security-domain>jaspi-module</security-domain>
   </jboss-web>
   

4. The application is deployed inside wildfly and can be tested using curl: the hello endpoint is not allowed for anonymous users; user1 can access and receives the hello; but user3 is forbidden (this user lacks the valid role).

   
   curl http://localhost:8080/hello-world-jaxrs/api/hello
   <html><head><title>Error</title></head><body>Unauthorized</body></html>
   curl --anyauth --user user1:password1 http://localhost:8080/hello-world-jaxrs/api/hello
   Hello user1!
   curl --anyauth --user user3:password3 http://localhost:8080/hello-world-jaxrs/api/hello
   <html><head><title>Error</title></head><body>Forbidden</body></html>
   

   So it is working. The old configuration for JASPI in wildfly is simple. A security domain was the only way of using this standard until wildfly 15.

5. Time to use the new JASPI elytron way. The old security domain is removed and a new jaspi-configuration is needed inside the elytron section.

   
   /subsystem=security/security-domain=jaspi-module:remove
   /subsystem=elytron/jaspi-configuration=simple-configuration:add(layer=HttpServlet, application-context="default-host /hello-world-jaxrs", server-auth-modules=[{class-name=es.rickyepoderi.jaspi.ExampleServerAuthModule, flag=REQUIRED, module=es.rickyepoderi.jaspi, options={"user1" => "password1###user,role1", "user2" => "password2###user", "user3" => "password3"}}])
   

   The new elytron configuration assigns JASPI to the application context, but the rest is more or less the same than in the old way (class and module, and the same configuration to define our three users).

6. Then JASPI needs a security domain to be created for the web layer undertow.

   
   /subsystem=undertow/application-security-domain=jaspi-module:add(security-domain=ApplicationDomain, enable-jaspi=true, integrated-jaspi=false)
   

   The domain uses the default ApplicationDomain, but please note that the option integrated-jaspi is set to false. This means that the JASPI module is enough, an ad hoc identity will be created independently of the domain realm. The default value true uses the realm in the ApplicationDomain to locate user and roles, so, besides the JASPI authentication, it also requires the user to be present in the realm.

7. Finally the same curl commands of step 4 can be executed. They should return the same output.

That is all for today. The new elytron security provides the old fashioned JASPI authentication since wildfly 15. The idea is more or less the same than in the old sub-system and, in general, the steps to configure it are very similar. Both configurations work, so, if you are using JASPI for your applications, better start using the new elytron way. The two little projects used in the entry (the JASPI module and the hello application) can be downloaded using the links provided before.

Best regards!