Back when the USPS SOAP Service was young and the SSDT/OECN first started work on what is now the MCOECN Kiosk, we needed a way to authenticate "all employees of a district". We had never done this sort of thing before. Although many employees have email or other logins at the district or ITC, each organization used a different directory (ADS, VMS, others) and "many" is not the same as "all". The only list of "all employees" existed inside the USPS database itself.
So we decided we could use the USPS SOAP service as a user directory if we just added an "Employee PIN" to the USPS database and exposed it as a property of Employee object in the SOAP service. We'd allow the SOAP clients to retrieve and update the PIN via the normal SOAP service API. Then applications like Kiosk, could build authentication processes on top of this field. From the USPS side, it was simple and easy and also dumb.
This is probably not the worse design decision I've made in my career, but it ranks in the top ten. Pretending that a single field creates an authentication system, was wrong headed and creates a number of problems, including:
- The password is not encoded (it's stored in as plain text), there's no expiration, complexity requirement, etc.
- The password is shared with any application using the SOAP service. Even if an application is trusted to access USPS, it should not automatically be trusted with employee credentials.
- The password is audited just like any other field in USPS. So when an employee changes passwords, it creates audit log in USPS which confuses users (and exposes the password again in text reports).
A few years ago, we recommended that the Kiosk project discontinue use of the USPS Employee PIN and take over full management of the employee authentication. They can still use USPS to identify employees (using email address), but once the user is identified the credentials should be stored and managed in the application.
At the time we made the recommendation, we believed the Kiosk as the only application using the PIN. Apparently, there are other applications that have cropped up which are also using it (and treating it like a SSO solution with Kiosk). So the SSDT extends recommendation to these applications as well. If you're using the Employee PIN, it is, and was, a bad idea and you should find another solution.
Unfortunately, the Employee PIN is part of the API of the SOAP service, so we can not removed it completely without breaking backwards compatibility. So the field will remain usable under USPS Classic. However, for the USPS Redesign, we currently plan on removing the fields and disabling it in the SOAP service.
-djs