• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Devaka Cooray
  • Jeanne Boyarsky
  • Bear Bibeault
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • salvin francis
  • Carey Brown
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

Comprehensive security when you're part of a company that is a conglomeration of several mergers.  RSS feed

Ranch Hand
Posts: 144
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I work for a large corporation, formed in large part by adding several other companies in its business area, and each one had their own security system(s) for single sign-on authentication, *MANY* different authorization mechanisms (almost one per app with 1000+ users), etc.

How do you start to join all of these various systems together? Do you build a "wrapper" that, based on some code associated with a user or system - like 'legacyX' or 'legacyY' - would direct you to the authentication/authorization
servers/DBs of that particular division that was grafted in? That would be a maintenance nightmare, I'd think, once users start to cross over and use apps from a different legacy group.

Do you attempt to move all authentication into one platform and give users "roles" that various apps can use to do authorization? A lot of work, and unfortunately politics start to take over here ("Mine's the best".. "No, mine's the best").

Also, one that involves "single company" systems.. If I'm an admin on AppX, a viewer on AppY, and an editor/reader on AppZ, how best to handle this? Centralize all the roles I have in one place? Allow each app, based on my email
or other userid, to define my role within that app? A hybrid of the two? Something else??

There are a myriad of permutations of the above scenarios I pointed out.

Just wondering a few things:

1.) Jeremy, does your book (or do you have some you could post here) contain any case studies or pointers on best practices for people in this situation?
2.) Does anyone else have experience trying to somehow "glue" various authentication/authorization systems/methods together into a cohesive whole?
3.) What about the "I have different roles depending on the application" issue? How have folks out there dealt with that one in a multi-application environment?
Posts: 6
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Thank you for the question. The situation you find yourself in is pretty common for organizations that grow by acquisition. I am not a proponent of standardizing on a single platform as a hard and fast rule, but I do think having too many authentication mechanisms makes implementing true Concept of Least Privilege or effective Role Based Access control difficult. My recommendation would be to start by building a matrix that lists the different authentication systems, who is responsible for each system, and any unique capabilities of the system that the stakeholder feels cannot be replicated in a different system. Once that matrix is built, a governance group can start to decide where overlap can be eliminated and efficiencies can be gained. There will certainly be a political element in this process, but it is worthwhile to do the hard work up front to avoid major problems in the future.

I do not know of a wrapper that can do what you describe, but such a wrapper could help bridge the gap between disparate systems and a more centralized system. If you can accomplish it from a people and process perspective, I think building a platform with proper Role Based Access Control is probably the best solution from a governance perspective. I would use Active Directory (or an equivalent) as the system of record in terms of identity and each application would have a separate set of permissions.

The process I have described above has been used in a variety of contexts in my career from authentication to encryption and countless other security systems as well. The key is starting by building a group of stakeholders and having them buy into what you're trying to accomplish.
All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!