Help Center

Getting Started with Nému Capture

This documentation is a work in progress.  Please contact Support for assistance if you need additional help while we get this sorted out.

Introduction

Hello, and welcome to Nému Capture!  We built Capture to help simplify the process of capturing and onboarding smartcard users into your cloud application stack.  It's something you've probably run into before, considering that cloud systems aren't typically integrated with the on-premise Active Directory infrastructure you use to issue and manage your users' smartcards.  Using this product, this becomes a breeze: You can either use this portal to onboard users into your system starting with the information on their smartcard, or you can use it to associate their smartcard with existing application accounts - to step up to a higher level of authorization, for example.

Currently, Nému Capture supports integration with the industry-standard Okta identity-as-a-service suite.  Onboard or upgrade your Okta users to Smartcard users without needing a helpdesk or an administrator to sit down and enter everyone's smartcard information into Okta!

We are working on adding support for other user management systems as well; Our roadmap is targeting loosely federated ADFS and Oracle Identity Management systems initially, and adding support for other cloud-based IDaaS solutions (OneLogin, Sailpoint IdentityNow) beyond that.


Planning

Capture is intended to be easy to manage; Our initial release is available in Amazon AWS Marketplace as an Alpine Linux-based appliance.  We recommend using this within a CloudFormation template or AutoScaling Group to provide maximum flexibility and ensure you are able to easily manage configuration and update deployments.

The first thing to consider is what kind of workflow your organization needs. Are you using Capture to onboard new users, or are you using it to provide stronger step-up authentication for applications that deal with more sensitive data?

After that, you'll need to decide whether your process will be open to all users that have a smartcard, or only to users that are using smartcards from your organization.

Finally, estimate how many users you will need to onboard using this process.


Configuration

You will be configuring Nému Capture using a simple JSON text file, which will either be uploaded to a static EC2 instance, or provided to it in the user-data section of the instance's configuration.  Here is a basic configuration file that will demonstrate most of the things that will need to be setup before you can operate:

{
    "PortalURL": "https://localhost:8443",
    "AuthURL": "https://localhost:8444",
    "AllowRegistration": false,
    "AllowedDomains": [
        "nemuconsulting.com"
    ],
    "Web": {
        "HTTPAddress": "0.0.0.0:8080",
        "HTTPRedirectTo": "https://127.0.0.1:8443/",
        "SSLAddress": "0.0.0.0:8444",
        "PortalAddress": "0.0.0.0:8443",
        "CertPath": "server.crt",
        "KeyPath": "server.key"
    },
    "Customization": {
        "PortalName": "Card Registration System",
        "OrgName": "MyCompany",
        "OrgWebsite": "https://mycompany.com/",
        "HeaderBgColor": "#000",
        "HeaderTextColor": "#fff",
        "SupportDeskName": "Support Desk",
        "SupportDeskEmail": "[email protected]"
    }
}

Note that Capture runs on three ports, two of which are generally required to operate. The HTTP port, the Portal port, and the PKI port.

The HTTP port is used to redirect users into the Portal, if you are not using this product behind a load balancer that can handle an http->https redirect on its own.

The Portal port provides a welcome screen to the users, to help explain to them the process they will be going through before they are prompted to authenticate with their smartcard.

Finally, the PKI port is configured to prompt them for their smartcard, and will read it and act appropriately depending on your other settings.

The CertPath and KeyPath variables provide you with the ability to set the SSL certificates associated with both the PKI and Portal ports.  If you do not specify these in your configuration, the server will generate a self-signed certificate on startup, which would generally only be useful if you are using a load balancer in front of this product.  Instead of providing these files on the server, you can set the value KeyPath to the full ARN of an Amazon Managed Secret containing the certificate and key and it will load the certificate from there on startup.

Set the AllowRegistration variable to true if you want the system to allow users to register for a new account using their smartcard;  Setting this to false will disable user creation, and will instead require them to login with an existing account, which their smartcard will be associated with.

To configure frontend authentication behind an Okta instance, you'll need to also add the following section to the configuration:

 "Oidc": {
        "Provider": "https://oktainstancename.okta.com",
        "ClientID": "XXXXXXXXXXXXXXXXX",
        "ClientSecret": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx"
    },

And in order to modify users within your Okta instance, the following:
    "Okta": {
        "Active": true,
        "Domain": "oktainstancename.okta.com",
        "APIToken": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
        "CreateUsers": true,
        "ActivateUsers": false
    },

Additional configuration options will be available for SQL, SCIM, AD, and Script/Lambda backends, as well SAML and HTTP Basic frontends soon.

Once you have your target configuration file created, it can be tested by launching a single EC2 instance with the configured JSON in the user-data field.

Deployment

We currently only support deployment via AWS, but the software does support on-premise operations, if you prefer to go that route.  If you need this functionality on your network, or in an airgapped network, please contact our Sales team for assistance.

Hat das Ihr Problem gelöst?