James Shield
Is there a projected date/release when JSON calls will be able to use an API Token, rather than relying on plain text email and passwords?
0
Comments
Please sign in to leave a comment.
We have a major security update that will change a lot of the O4 security - a bit of a big project including 2 factor authentication for user logins. (Still not sure if we will make that optional or not - likely will required.)
For JSON - there is an element we will likely make optional but force the system to only respond to an IP "white list". The issue is that someone somewhere will try to crack the system and using a white list for a given token makes sense.
Anyway - it will happen by the end of the year - but not sure of an exact date at the moment.
Thanks Brian, I'm in favor of mandatory multifactor authentication. Would it be possible to integrate this into Azure AD, or other identity provider (Google Identity, Facebook Workplace, etc.), for SOO and to take advantage of the conditional access security features available through these providers? My other preference would be to utilize an authenticator app, such as Microsoft Authenticator or Last Pass for the multi-factor. I'd really prefer to avoid sending a code via a text message, since cell phones are much easier to compromise and may leave with an employee when they are no longer with an agency.
In addition to white listing IPs, which may be difficult to maintain with 3rd party BI, automated flows, and cloud storage solutions all accessing Oasis data, will you use OIDC to secure the API tokens?
Right now I can't guarantee one way or another. The gotcha with software is we can imagine or state anything - it's only money to develop and (more importantly in my book) support.
Balance that with the hard reality that the lighting industry we serve just recently gave up Fax machines. (I said that to a group I was training last year and got the response, "but we still use the fax machine daily"!)
The good news: we are finally (3 years after the first deployment) getting serious use of the JSON APIs. With usage, I can see spending more development money on JSON. We just can't out spend the market. It's always a balancing act.
I get the chicken/egg scenario when it comes to development resources vs. usage, but I would imagine SOO and MFA would be a paid adder to the various O4 packages currently available. We would be willing to pay per seat count for the expanded feature set, so there is some opportunity there. Personally, I'm extremely hesitant to use a product that potentially exposes so much financial data without modern security in place to protect that information. The various identity providers have made their toolsets relatively easy to implement, so I don't see an advantage, financial or otherwise, in creating an alternate method that is less secure
At this point we are talking past one another. Easy to put up a list of todos on a development list (most of these are already their - so no fight on what needs to be done). Harder is knocking out the list with everyone demanding a different #1 to act on "now".
Mostly, I don't believe in security theater - and I've seen many examples out there. Integrating with any of the packages you specified is just the icing on the cake as anything we do has to map all the way throughout the system. That is I've seen "partners" where you get the token and login to their system, only to find the rest of the API kit is unprotected. We won't do that.
Security is one topic that we take seriously and continue to adjust within the software and with various tools (firewalls, logging, white/black listing, etc) we use. Since it is core to the system it doesn't work very well as an add-on for just one group - at least not to do it properly.
Anyway - look for more on this subject. We will do it properly which takes a little more time.