4 ms·
My primary role (these days) is as an Identity Architect. What that means is, I look at all the disparate systems in an organisation and design a better way to
by mattowen_uk 10y ago
My primary role (these days) is as an Identity Architect. What that means is, I look at all the disparate systems in an organisation and design a better way to manage credentials.
My main client base is Blue Chip, so that means a majority of Windows based services, and a smattering of Linux, and even mainframe. Most companies have totally disconnected systems requiring manual user creation on multiple systems, with the user having to remember several sets of credentials just to do their daily job. This may be archaic compared to the proliferation of oAuth across the web, but large Corporates are rarely up to the curve, and in many cases are completely unaware the curve even exists. This is where I come in.
The main component of any credential management is an identity hub; I mostly work with Microsoft Identity Manager, but there are other options, such as IBM Tivoli Identity Manager and Cisco Identity Services Engine (to name but two). The identity hub takes data from [multiple] Authoritative Sources (HR, SAP etc.) and compiles a meta-identity of each user which is then forwarded as user attributes onto target systems. If the target system doesn’t need or care about ‘Job Title’ for example, that can be excluded from the forwarded data. Any user changes in the Authoritative Source are then replicated automatically to any target system on a regular schedule.
Once you have a Single Identity, it is then a case of leveraging SAML, oAuth, or plain old Kerberos/NTLM for login authentication. In an ideal scenario all systems will be able to support a compatible logon provider service but that isn’t always the case. Getting users down to a single id/password is always the end goal though.
Of course this also all scales out to the Cloud, with direct support for AWS, Azure etc.
If you want to know more, hit me up with some questions!
- ashitlerferad 10y agoDo you deal with any situations where public/private keys are used instead of passwords?
- Jaruzel 10y agoYou can store the keys in the Identity Hub, or in Active Directory - providing the logon provider is supported it should work.
- yardie 10y agoI'm currently P2Ving a lot of old servers. Identity management is in my hit list for the year. So yeah, I'm interested and would like to subscribe to your newsletter
- Jaruzel 10y agoCool - I've been toying with starting a small IDM blog for a while now, I might just actually sort it out now ... :)
- L_Rahman 10y agoI'm building a product in this space and would love to get your feedback if you're interested. My email address info is in my profile.
- zhte415 10y agoJust a small note: Thanks. Having joined a mega-corp in 2010, around 250,000 people, there was a big migration of 1000s of disparate systems to 'Single Signon', a slogan displayed under a login button. It was an ongoing process, and when that little slogan appeared under the login for nth intranet app, it was a small sigh of relief. So thank you. And an interesting description of how simple it seems to do given the other system plays nice. What do you do with things like SharePoint where users at any levels can add fields to profiles, and these fields can be changing all the time? Just have a massive profile template constantly adding fields?
- Jaruzel 10y agoThis is where information governance comes in. It's fine to add bespoke profile fields in SharePoint (or any other app), and the Identity hub is will just ignore them if it's not got rule defined. If it's decided that the 'favourite animal' field is to be pushed out to other apps, then a new rule is added to the Identity sync process. It's all fail simple as you say; the main problem always tends to be departmental politics.