So we have this service at work...
-
Which was build by a real good programmer before my time, which allows our various business groups to connect to an external 3rd party API. So far so good... Each of the business groups has their own profile with that the external resource; they have a GUID for a license and an alias so that it is easy to see which group any GUID is associated with. Still good... We have developed the applications that utilize this service for all but one of our business groups. The last thinks they are good enough to do their own thing. Fine. Their applications group has about 3x the staff as ours so let them do their own thing. OK.... Now they want full access to our DB or an API so that they can lookup their historical requests. Ummm... we'll do an API thank you. Blueprint it up to require the key and their CustomerID... No, authentication/authorization is not needed as this will be an internal API only. Oh we're starting to go downhill now.... From prototypes I had to do their requests manually, had this new API up in a couple of days. Now the problems come into view. 1. On our side of the wall, what do you mean there is no auth required. 2. And from them, we don't know our key. Whomever on their side compiled an assembly so that they could just use their Alias for identification, and they don't have the source code. Ugh... So the politicians settled on this mind-number yesterday afternoon: 1. A new GUID will be created on our end for each business group. 2. A new endpoint is created where they give us their alias, and we will return this new GUID. 3. Prior endpoints will be rewritten- 3A. Instead of their license key being required, they will pass in their alias instead. 3B. The requests will require an Auth request header, containing the new GUID. Yep... glad I have today off. Need to have it ready by Monday end-of-business.
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
-
Which was build by a real good programmer before my time, which allows our various business groups to connect to an external 3rd party API. So far so good... Each of the business groups has their own profile with that the external resource; they have a GUID for a license and an alias so that it is easy to see which group any GUID is associated with. Still good... We have developed the applications that utilize this service for all but one of our business groups. The last thinks they are good enough to do their own thing. Fine. Their applications group has about 3x the staff as ours so let them do their own thing. OK.... Now they want full access to our DB or an API so that they can lookup their historical requests. Ummm... we'll do an API thank you. Blueprint it up to require the key and their CustomerID... No, authentication/authorization is not needed as this will be an internal API only. Oh we're starting to go downhill now.... From prototypes I had to do their requests manually, had this new API up in a couple of days. Now the problems come into view. 1. On our side of the wall, what do you mean there is no auth required. 2. And from them, we don't know our key. Whomever on their side compiled an assembly so that they could just use their Alias for identification, and they don't have the source code. Ugh... So the politicians settled on this mind-number yesterday afternoon: 1. A new GUID will be created on our end for each business group. 2. A new endpoint is created where they give us their alias, and we will return this new GUID. 3. Prior endpoints will be rewritten- 3A. Instead of their license key being required, they will pass in their alias instead. 3B. The requests will require an Auth request header, containing the new GUID. Yep... glad I have today off. Need to have it ready by Monday end-of-business.
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
Sure, now they say no authorization is required because it is internal-only. That's often the convenient statement of the moment. However, reality often diverges from the agreements of the moment. I would get something in writing, signed by a CIO or executive of your choice, saying that no security is required. This is because when this gets hacked and your database is trashed you need to be able demonstrate you were ordered to allow open access. This is the classic case of a cover-your-backside requirement because you have been asked to do something absurd.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"