last week i was at a meeting at one of the financials, and it was no surprise that they want to talk hard cost cutting. they want to get everything they can onto their low cost, well run MSFT platforms. at the meeting are myself and the account manager who brought me in as well as another sales rep and their accompanying talking head. it must be fun for clients to schedule dueling consultants. i know i would in their shoes.
everyone was on the same page at the start. the topic was how to get their LDAP user stores into either AD or ADAM as easily as they can. they were reserving the choice between AD or ADAM for later. the conversation strayed a bit and we were talking about how they also wanted to get SSO for their external users out of this if they could. the other consultant kept dismissing my claims that they were going to have to go through a transition period due to their stated need to keep some users on LDAP longer than others. it went in circles until i asked him to lay out his plan. “First,” he said “you move everyone to ADAM”. the head architect from the client and i smiled at each other.
wasn’t the point that they could not just “move everyone to ADAM”? so many people seem to miss the part in the middle where both the old and the new have to work together for a while. and if you can’t see that, then you’re not seeing the real problem. if we could just snap our fingers and put everyone on shiny new tech all the time, shops like QSFT would be out of business. it’s all the hard parts that people get stuck on in the middle of these projects that make it interesting…
Showing posts with label sso. Show all posts
Showing posts with label sso. Show all posts
Monday, April 13, 2009
Tuesday, March 24, 2009
8 weak doors or one strong one?
lots of talk about sso and authN at TEC 2009. what fascinates me is how many people are espousing the merits of having completely different credentials for many systems. they all claim that the reason is security (at least all of them that i have heard). one of our senior products folks has an analogy they use that i like to discuss this. he will ask, if you were building a house would you want 8 weak doors or one strong one? and i think that really gets to the heart of the security issue.
but even if you grant that perhaps many credentials could potentially be stronger than one, the question becomes what is the trade off? basically, we’ve been working de facto under the multiple credential world for the whole open systems era and no one thinks we’re in a good security state. i would submit it’s because of all the other issues that come from many credentials like more to manage and burden on the users. so i’d ask if there is really a way to get rid of the burden on the users and maintenance issues? some say synchronize, but then you have one door again (or at least one key that works on all the doors). and now you have extra infrastructure on top of what you already have.
sso and AD briding has a role. so does sync. but whatever the stuff that powers this stuff, sso seems like it will always be the one strong door when it’s done right. what do you think?
but even if you grant that perhaps many credentials could potentially be stronger than one, the question becomes what is the trade off? basically, we’ve been working de facto under the multiple credential world for the whole open systems era and no one thinks we’re in a good security state. i would submit it’s because of all the other issues that come from many credentials like more to manage and burden on the users. so i’d ask if there is really a way to get rid of the burden on the users and maintenance issues? some say synchronize, but then you have one door again (or at least one key that works on all the doors). and now you have extra infrastructure on top of what you already have.
sso and AD briding has a role. so does sync. but whatever the stuff that powers this stuff, sso seems like it will always be the one strong door when it’s done right. what do you think?
Subscribe to:
Posts (Atom)