Tuesday, July 08, 2008
How come folks only use SAML in server scenarios?
I would love if Oracle, Sun and others pushed Microsoft to consider putting SAML support in Windows...
Every morning, I blindly get logged into our Intranet site. While having some clue as to how it works, I never really thought about how the technology behind it could be made better. Many of the web access management tools (e.g. OpenSSO, Siteminder, Oblix, etc) are typically used in enterprise portal settings where the goal of reducing signon's is pervasive. In our intranet site, we use one of these tools that redirects itself through a couple of URLs of which one is a Windows server. Its sole purpose for doing this is that Sun Solaris nor Linux have any ability to pick up the credentials of a currently logged in user, but IIS when used with IE does.
My limited understanding of how Windows could be extended, would be to somehow hook the GINA APIs such that Windows itself could become a SAML provider where the web access management products could simply become relying parties and read the credentials via SAML. This would eliminate the need for Windows servers for use with Web Access Management. It would also seem to me that if GINA can be controlled by Group Policy Objects, that one could also avoid having the overhead of enterprisey deployments of ADFS and that federation could happen in a much simplier fashion.
For example, I am currently logged into my own network and upon invoking Internet Explorer (There are APIs to set cookies), I could be signed onto say www.burtongroup.com without having to specify any username/password. Before passing it along, the local certificate provider could sign the request and pass it along. Since there are multiple certificates on Windows clients that belong to a domain, the only thing the administrator would have to noodle is in making sure that their AD domain is Internet routable and has a certificate issued by a Root CA.
The problem with most federated approaches is that it is meant for one large enterprise to talk to another large enterprise. What happens when a small business of say five employees wants to talk with a large enterprise? Today, there are pieces of the equation but not much of it is scalable (in the human sense) nor sustainable. It seems as if Kim Cameron and company are solely focused on consumerish interactions and are leaving small businesses to fend for their own.
Taking this one step further, imagine if Microsoft actually made it even easier to develop GINA applications by having special Wizards in Visual Studio that wired it all together. I wonder what would happen if I submitted this as an enhancement request to Curt Devlin, Allan De-Costa Pinto and other Microsoft types on my side of town...
| | View blog reactionsEvery morning, I blindly get logged into our Intranet site. While having some clue as to how it works, I never really thought about how the technology behind it could be made better. Many of the web access management tools (e.g. OpenSSO, Siteminder, Oblix, etc) are typically used in enterprise portal settings where the goal of reducing signon's is pervasive. In our intranet site, we use one of these tools that redirects itself through a couple of URLs of which one is a Windows server. Its sole purpose for doing this is that Sun Solaris nor Linux have any ability to pick up the credentials of a currently logged in user, but IIS when used with IE does.
My limited understanding of how Windows could be extended, would be to somehow hook the GINA APIs such that Windows itself could become a SAML provider where the web access management products could simply become relying parties and read the credentials via SAML. This would eliminate the need for Windows servers for use with Web Access Management. It would also seem to me that if GINA can be controlled by Group Policy Objects, that one could also avoid having the overhead of enterprisey deployments of ADFS and that federation could happen in a much simplier fashion.
For example, I am currently logged into my own network and upon invoking Internet Explorer (There are APIs to set cookies), I could be signed onto say www.burtongroup.com without having to specify any username/password. Before passing it along, the local certificate provider could sign the request and pass it along. Since there are multiple certificates on Windows clients that belong to a domain, the only thing the administrator would have to noodle is in making sure that their AD domain is Internet routable and has a certificate issued by a Root CA.
The problem with most federated approaches is that it is meant for one large enterprise to talk to another large enterprise. What happens when a small business of say five employees wants to talk with a large enterprise? Today, there are pieces of the equation but not much of it is scalable (in the human sense) nor sustainable. It seems as if Kim Cameron and company are solely focused on consumerish interactions and are leaving small businesses to fend for their own.
Taking this one step further, imagine if Microsoft actually made it even easier to develop GINA applications by having special Wizards in Visual Studio that wired it all together. I wonder what would happen if I submitted this as an enhancement request to Curt Devlin, Allan De-Costa Pinto and other Microsoft types on my side of town...
