Re: KB 834489 - workarround
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 08/23/05
- Next message: Isaac: "Re: Event ID 537 Digest Authentication"
- Previous message: David Wang [Msft]: "Re: Use of Client Certificates"
- In reply to: Ran Davidovitz: "Re: KB 834489 - workarround"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 22 Aug 2005 23:20:23 -0700
> Because I want the users to be able to enter the portal without
> entering username / password - I mean I want them to pass
> it in the query string.
Why do you need to pass it on the URL somehow? Is your portal implementing
some sort of custom authenication scheme that requires this?
> And because Microsoft disabled that option to pass
> credentials in the query I cannot accomplish this.
Correct, and this is by-design. Microsoft is obligated to close the security
vulnerability even if it breaks your application because only then do you
have the choice and responsibility of determining whether to re-opening the
security vulnerability, or choosing a secure alternative.
I guess I just do not understand why you need to pass user credentials over
the URL because using pure Basic + auto-authenticate should be sufficient to
SSO. The only way I see that failing is if you are relying on custom
authentication, and since you are not describing what is broken about it, I
cannot offer any more advice.
-- //David IIS http://blogs.msdn.com/David.Wang This posting is provided "AS IS" with no warranties, and confers no rights. // "Ran Davidovitz" <ran.davidovitz@verint.com> wrote in message news:%23Zc$%23i5pFHA.2072@TK2MSFTNGP14.phx.gbl... The basic authentication is not 100% solution Because I want the users to be able to enter the portal without entering username / password - I mean I want them to pass it in the query string. And because Microsoft disabled that option to pass credentials in the query I cannot accomplish this. "David Wang [Msft]" <someone@online.microsoft.com> wrote in message news:%23yx4VhipFHA.3380@TK2MSFTNGP12.phx.gbl... > Browse through some of my blog entries to understand more about what you > are > trying to do and why things work the way they do. > > http://blogs.msdn.com/david.wang/archive/2005/07/06/SSO_ISAPI_Considerations_2.aspx > > Based on what you have said, I think the simplest solution is to have two > websites, both pointing to the same content: > 1. Intranet website uses Integrated authentication > 2. Internet-facing website uses Basic+SSL > > From home without VPN, Employees sign on using Basic over SSL and the > browser is instructed to "trust" and auto-authenticate to the > Internet-facing website. From work, Employees are already logged in and > just > work. > > -- > //David > IIS > http://blogs.msdn.com/David.Wang > This posting is provided "AS IS" with no warranties, and confers no > rights. > // > "Ran Davidovitz" <ran.davidovitz@verint.com> wrote in message > news:ebteOchpFHA.2580@TK2MSFTNGP09.phx.gbl... > What we are trying to achieve is a single-sign on mecahnism. > > Our customer has a broadvision portal on the internet and he would like > his > employees > to be able to get to our server through the portal from home. (without > VPN) > > His employees log into the portal and through there they can get to many > applications > so it is a business requirement to implement SSO (single sign on). > > our server is based on iis and which needs to get the credentials in one > way > or the other > in order to validate the user and authenticate him. > > "Ran Davidovitz" <RanDavidovitz@discussions.microsoft.com> wrote in > message > news:DB88F3C3-31AE-482F-8D9A-76BC645B8B74@microsoft.com... >> The customer used basic authentication, he cannot use integrated. >> I don't want him to authenticate using a form. >> >> I don't want the user to type his auth (I want to simulate "SSO") - The >> main >> requirement is not to write credential again. >> >> And the workaround is not clear enough (I have looked at it with some >> developers). >> >> Thank you for your response but it didnt help me yet :) >> >> "David Wang [Msft]" wrote: >> >>> Can you clarify what is confusing you from KB834489 >>> >>> I don't know how your authentication is configured and why your customer >>> is >>> passing username/password using the URL, so I cannot make a >>> recommendation >>> on how you can "support this issue (without updating the client side >>> registry)". >>> >>> Why are the workarounds from the KB insufficient? Why can't your user >>> just >>> type in username/password when prompted instead of having to type it >>> into >>> the URL request itself? >>> >>> -- >>> //David >>> IIS >>> http://blogs.msdn.com/David.Wang >>> This posting is provided "AS IS" with no warranties, and confers no >>> rights. >>> // >>> "Ran Davidovitz" <RanDavidovitz@discussions.microsoft.com> wrote in >>> message >>> news:A23D4555-1DCF-4D83-A165-FD8C9569599A@microsoft.com... >>> Hi. >>> >>> I have a customer that until today passed his username / password using >>> the >>> URL (using basic authentication). >>> >>> After reading KB 834489 I see that this behavior is not supported any >>> more. >>> >>> I dont understand what is the workarround described in KB 834489. >>> I want to know if there is another way that i can support this issue >>> (without updating the client side registry). >>> >>> * what ever solution i will do I must support intergrated security also. >>> >>> >>> > > >
- Next message: Isaac: "Re: Event ID 537 Digest Authentication"
- Previous message: David Wang [Msft]: "Re: Use of Client Certificates"
- In reply to: Ran Davidovitz: "Re: KB 834489 - workarround"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
