Under which user account does the AES server make SMS service calls? Is it possible for that user to generate a Key and place it onto my CM server so that I can dispense with the password when making these service calls?

I've already prove that CM will allow me to login without a password if I put my public key in my user/.ssh directory. I'd like to use this method with SMS calls, simplifying the security around password handling.

Thank you,
Tom Lynn

SMS users are authenticated against CM accounts. They are authenticated as CM users. The username and password must be supplied. They are passed from the SMS application to AES in the HTTP header, and AES passes the credentials to CM using a proprietary protocol.

Mike, you've told me all the things I already know. If I knew what user account AES used, I could create one name the same in CM and create and stage the public key. Given all that, it's reasonable to assume that CM could use the public key to authenticate. Again, is this possible, or is it simply a capability that Avaya did not consider when they designed the API?

Thanks - Tom Lynn

AES does not use a separate CM Administration account. It uses the login the application gave it in the SMS Web Services request on the AES-CM session the application triggered to be created. This is because different applications have different access level permissions to CM information and the AES doesn't know what they are so it could multiplex multiple applications into a single AES-CM connection. The permissions restrictions are implemented by virtue of Communication Manager administration permissions granted the login that the application utilizes.

There are no public keys, there is a login and an associated password. Keep in mind the authentication portion of communication manager was designed in 1980 and aside from implementing encryption on the signaling path between the client (application such as Avaya Site Administrator, and AE Services and other applications that use OSSI), and some rearrangement of the security subsystem within Communication Manager along with migration from serial port connections to IP, little else has been done.

Your ability to use a ssh session and get logged into the SATis connectivity between a particular CM port and the SAT interface, and the level of permissions imposed on the login that you utilized. I could set it up differently and a ASG password prompt would always occur regardless of the user/ssh settings on the originating system.

Thanks Mike and John. I understand the existing auth mechanisms that are in place. I understand it's a pretty old arrangement. I'm in an IT group that places a lot of emphasis on security, single sign-on tools and generally frowns on our scripts having to handle passwords.

I'm simply trying to build a better mousetrap.

Keeping in mind that your level of expertise with SSO, key based authentication, and the like will far exceed mine, if you want to private message me (that P.M. button below) a write up of your best case scenario for how you would like to see it work, I would be happy to pass that to the AE Services product manager and perhaps facilitate a conversation whereby you could make these requirements you have known to the 'right' individuals within Avaya who could act on them (resources permitting of course).