Badge Readers and Cards

The badge readers and card types IDmelon Authenticator supports on shared Android devices, and how to set up badge login for them

Badge login reads an identifier from the card a user taps and matches it against the badges enrolled in your IDmelon workspace. This page lists the readers and cards IDmelon Authenticator supports on a shared Android device, and the shared_login_method settings that decide which reader is accepted and which identifier is read.

Supported readers #

By default every reader is accepted. Set model to a single reader to accept that one only — taps on any other reader are then ignored without a message. The device reads badges only while IDmelon Authenticator is open on the screen.

USB smart card readers #

• Any USB smart card reader that follows the CCID standard and exchanges data at APDU level works. Readers that have been tested include the ACS ACR1252 and the HID OMNIKEY SE Plug. There is no brand to configure: readers that report the serial in reverse byte order, such as RF IDeas readers, are recognized and corrected automatically.
• The device must support USB host (OTG). Connect the reader directly to a USB-C port or through an OTG adapter.
• The first time a reader is connected, Android asks whether IDmelon Authenticator may access it. Accept the prompt while you stage the device. Android asks again after the reader is reconnected or the device restarts.
• Reading HID PACS identifiers needs a reader that supports HID’s PACS commands, such as an HID OMNIKEY reader. Other readers can still read the card serial. Readers that only release PACS data over HID’s encrypted secure channel are not supported yet.

Keyboard-wedge readers #

These readers type the card’s identifier as if it came from a keyboard, over USB or Bluetooth.

• Set the reader to type the card serial as a decimal number followed by Enter. Any other output — hex, or surrounding characters — is rejected with “This device is not set up for this card."
• Keys typed into a text field go to the field, and keys typed slower than a reader types are never mistaken for a badge.

The phone’s built-in NFC #

The phone’s NFC controller only ever sees the card serial, so it cannot read HID PACS identifiers. A phone held to the device to present a mobile credential is refused, because it reports a different serial on every tap.

IDmelon Hub #

The Hub, previously referred to as the bridge, reads the card itself and sends the finished badge ID to the device. The card settings described below do not apply to it.

Supported cards #

• HID Seos cards answer only a reader that holds the keys for your Seos credentials. Without them the read fails and the user is asked to tap again.
• HID Prox is a low-frequency (125 kHz) card, so the reader must support Prox cards.
• A card whose serial changes on every tap cannot identify its holder, and is refused as unsupported. That covers every Seos card’s serial, which is why Seos is always read through PACS, and phones presenting a mobile credential.

Configure badge login #

Badge settings go in the shared_login_method key of the app configuration policy:

{
    "type": "badge",
    "model": "smart_card",
    "config": {
        "type": "Seos",
        "id_type": "PACSD",
        "prefix": "set"
    }
}

Values are not case-sensitive. A value the app does not recognize falls back to the default, so a typo never locks users out.

The minimal value, {"type": "badge"}, accepts every reader and reads the card serial.

Choose these settings to match how badges are enrolled in your IDmelon workspace. The same card produces a different badge ID under each setting, and a tap read one way will not match a badge enrolled another way.

Badge ID formats #

The same card can be reported in several ways. The examples are from one HID Prox card, except the serial, which is from a MIFARE card.

PACSD and PACSH split the credential into its fields, so they only work for the Wiegand formats the app recognizes:

• H10301, 26-bit, with a facility code and card number.
• H10302, 37-bit, with a card number only. It has no facility code, so it is reported as paxd- or paxh- followed by the card number.
• Corporate 1000, 48-bit, with a company ID in place of the facility code.

For any other format, use PACSR, which reads the raw bit stream and works for every card. With config.prefix set to reset, the same values are reported without their padd-, pahh-, paxd-, paxh-, or par- prefix. Use it only if your badges are enrolled without those prefixes.

What users see when a read fails #

Troubleshooting #