/ 
Concierge-Auth-v0.5.0
/ Concierge::Auth

NAME

Concierge::Auth - Factory/dispatcher for Concierge::Auth backends

VERSION

v0.5.0

SYNOPSIS

use Concierge::Auth;

my $auth = Concierge::Auth->new(
    backend => 'Concierge::Auth::Pwd',
    file    => '/path/to/auth.pwd',
);

# $auth is a Concierge::Auth::Pwd instance -- use it directly:

my $result = $auth->enroll('alice', 'secret123');
my $result = $auth->authenticate('alice', 'secret123');
my $result = $auth->is_id_known('alice');
my $result = $auth->change_credentials('alice', 'newsecret456');
my $result = $auth->revoke('alice');

DESCRIPTION

Concierge::Auth is a thin factory that resolves a backend class name to a live backend instance. It performs no guessing: backend must be a fully-qualified, already-resolved class name (e.g. Concierge::Auth::Pwd), not a friendly short name like 'pwd'. There is no default backend and no lc()/string-mapping performed here.

Resolving a friendly name (such as a backend value read from a config file) to a fully-qualified class name, and validating that every setting the chosen backend needs is present, is a desk-build-time concern handled by Concierge::Desk::Setup (see its backend catalog, %AUTH_BACKENDS), not by this module. By the time Concierge::Auth->new is called, that resolution has already happened once, not on every call.

The named backend module is required dynamically inside new -- this module does not use any concrete backend at compile time. A desk configured for Concierge::Auth::LDAP, for example, never loads Concierge::Auth::Pwd at all.

Unlike Concierge::Sessions, which wraps its backend inside a { storage = $backend }> container, this factory returns the backend instance directly. A conforming backend (e.g. Concierge::Auth::Pwd) already fully implements the Concierge::Auth::Base contract, so no wrapper object or delegation layer is needed -- $concierge->{auth} responds directly to authenticate/is_id_known/enroll/ change_credentials/revoke, and to the Concierge::Auth::Generators methods, with no extra indirection.

All remaining arguments passed to new (e.g. file for ::Pwd; host/bind_dn/password for a hypothetical ::LDAP) are passed straight through to the backend's own new unexamined -- Concierge::Auth has no opinion about what any given backend needs.

CONSTRUCTOR

new

my $auth = Concierge::Auth->new( backend => $class_name, %backend_args );

Loads $class_name (via require) and calls $class_name->new(%backend_args), returning the resulting backend instance.

Croaks if:

  • backend is missing.

  • The named class cannot be loaded (nonexistent module, syntax error, missing dependency, etc).

  • The backend's own new dies.

SEE ALSO

Concierge::Auth::Base -- the contract every backend must implement

Concierge::Auth::Pwd -- the built-in password-file backend

Concierge::Desk::Setup -- resolves friendly backend names (e.g. 'pwd') to fully-qualified classes and validates backend-specific required settings at desk-build time

Concierge::Sessions, Concierge::Users -- companion Concierge components

AUTHOR

Bruce Van Allen <bva@cruzio.com>

LICENSE

This module is free software; you can redistribute it and/or modify it under the terms of the Artistic License 2.0.