• 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 ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

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?
 
Author
Greenhorn
Posts: 6
5
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lanny,

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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!