Please note this is a very old project made for some ISPs and hasnt been maintained for years. Just kept here for reference.

What is IAM?
IAM stands for Interactive Authentication Manager. A more accurate description would be Enterprise Account Manager.
IAM is a system of master and client daemons with plugins to manage accounts across a great number of servers and have a central repository with multiple interfaces.
This system should support:
  • Any number of domains (example1.com, example2.com)
  • Any number of servers per domain (mail.example1.com, radius.example2.com)
  • Any number of account types per server (mail, radius, news, personal web, samba, shell)
  • Any number of accounts per account type
  • Any number of users per domain with any number of accounts
This hopefully means that IAM can manage any account on any server you have to manage. Provided that the server can run IAM and the account can be managed by plugin scripts.

Why was IAM created?
I was working for an ISP as a System Administrator and I needed a way for myself and others to manage our customer accounts that existed on many servers local and in remote POP's. I needed a powerful sysadmin class interface for myself, and the customer support people needed a more simple interface. I looked around for a long time and could find nothing that would do what I needed or wanted and was open source.
Since I have benefited soo much from the open source community I wanted to give something back. Hopefully this project will be worth something to someone else besides myself.

What platforms will IAM run on?
Short Answer: Linux
Longer Answer: Linux, Other *nix will probably work, and Windows through cygwin or ActiveState's ActivePerl. I also started to write some account plugins with the Win32 Perl modules.
IAM is currently running in Linux Production enviroments. Other *nix and Windows have not been tested or used in production enviroments... yet.

What was IAM written in?
IAM master and client daemons are written in Perl, and the plugins must be written with perl modules. Though I plan to allow the plugins to be written in any language.
I have thought about rewriting IAM in C/C++ but I do not know C/C++ very well yet. And I certainly would not know how to make the code cross platform.

What is IAM's current status?
Stable with a BUT. IAM has been running in production at several ISPs and a couple tech companies for about 2 years now. However these installs were all performed by me. No one else has yet attempted to setup an IAM system, mostly because I was just recently given permission to open source the code (3-19-2003). Since I have been the only person to create/install/maintain IAM, I am certain it has bugs, inefficiencies, and other crazy stuff in it.

What kind of accounts will it manage?
IAM relies heavily on plugins to do most of the real work. If the accout management can be scripted through perl, they can likely be managed by IAM.
I have written plugins for:
  • Mail (postfix, sendmail, cyrus)
  • Radius (XTRadius, Cistron Radius)
  • Samba
  • Personal Web Space (Apache, proftp)
  • NIS/YP
  • Unix Accounts (or shell accounts)
  • Windows User accounts (partially working with Win32 perl modules)
But since each of those systems have a huge variety in configurations the plugins usually need to be customized or rewritten to suit the specific needs of the account.
For example: My proftp has been configured for quota and mysql support for virtual ISP users. So the plugin was written just for that.
It is almost assured that you will need to make custom plugins for each of your account types to satisfy your unique enviroments. To me, this is a strength of IAM. This means the system is always custom made to fit any situation. But the customization is isolated completely in the plugins.

How does IAM work?
  • Users are managed through a UI that speaks with the master daemon.
  • Any request (create, delete, modify, etc.) is given to the master daemon
  • The master daemon looks in its database to see what server and plugin handle that account type that is to be modified
  • The master daemon records the request in a transaction table then hands the request off to the remote client IAM daemon that exists on the server that houses the account.
  • The client daemon then calls the appropriate plugin with the supplied arguments
  • The plugin then completes the request and hands back a response (success, failure with reasons) to the client daemon
  • The client daemon hands back the response to the master daemon
  • The master daemon records the response in the transaction table then hands back the response to the UI
  • The UI parses the response and displays it in a pleasing way to the user
This way the transaction table will record every single change ever made to the account.
Hopefully I have stored enough information here to allow events to be rolled forward and backward like a database. Though this rollback functionality hasnt been written yet, it has been planned for.

What about security?
Since IAM has to talk with servers over known and unknown networks I wanted to secure it as much as I could. IAM does support communications with SSL and has a one-time-password like authentication mechanism. Though since I am not security expert or programming guru, I am sure there are better ways of implementing these things.

Anything else I should know, or you want to tell me?
IAM represents some of 'firsts' for me. My first perl daemon. My first perl network communications. My largest database project. As a result I am sure there are alot of things I coded that you all could do better, faster, more efficient, more robust, etc. This is another reason I am open sourcing the code. I am hoping the community can help make IAM better than I can alone.

Innominatus
© 2003 Jason Jorgensen