Advice: .NET Authentication
-
Hello, I need advice. I have created a series of ASP 3.0 and ASP.Net applications. I am currently in the process of trying to create a global groups and authentication system that works across all applications. I would like to create something similar to Active Directory, where the database can be replicated and updated anywhere. My concern is, I don't want to tie all of my applications to one database. If that database were to fail it would shut down all of my applications. Has any created anything like this? Does anyone have any articles that reference this type of situation? I also need to figure out an efficient and secure way to transfer users from one application to the other application without having to relogin. I assume I will use some sort of transfer token or something. Also, I know that ASP.Net Form authentication can work across multiple apps if you setup the encryption keys manually. I am not sure if this is the right solution for me. Thanks, Jon Vickers
-
Hello, I need advice. I have created a series of ASP 3.0 and ASP.Net applications. I am currently in the process of trying to create a global groups and authentication system that works across all applications. I would like to create something similar to Active Directory, where the database can be replicated and updated anywhere. My concern is, I don't want to tie all of my applications to one database. If that database were to fail it would shut down all of my applications. Has any created anything like this? Does anyone have any articles that reference this type of situation? I also need to figure out an efficient and secure way to transfer users from one application to the other application without having to relogin. I assume I will use some sort of transfer token or something. Also, I know that ASP.Net Form authentication can work across multiple apps if you setup the encryption keys manually. I am not sure if this is the right solution for me. Thanks, Jon Vickers
jon.vickers wrote: I would like to create something similar to Active Directory, where the database can be replicated and updated anywhere. My concern is, I don't want to tie all of my applications to one database. If that database were to fail it would shut down all of my applications. When is that not the case anyway? In a large, scalable architecture, your database server should be independent of the web server/garden/farm on which the application is deployed, and the database server itself can be clustered to provide redundancy... and it can exist in a master/replica schema as well, but in the end, there's your data in that database, and if it fails, you're hosed. On the other hand, you could simply use Active Directory, if you're willing to learn how to use ADSI -- 'cause why re-invent the wheel? jon.vickers wrote: efficient and secure way to transfer users from one application to the other application without having to relogin This sounds like sharing state between ASP and ASP.NET applications. There's one example here[^] and Google will yield about 42,000 more. ;) jon.vickers wrote: ASP.Net Form authentication can work across multiple apps You can store session state on a server designated to retain state or in a designated database server; also, place other applications in the same directory structure, so that each application inherits its parent's web.config, or overrides when necessary. What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
-
jon.vickers wrote: I would like to create something similar to Active Directory, where the database can be replicated and updated anywhere. My concern is, I don't want to tie all of my applications to one database. If that database were to fail it would shut down all of my applications. When is that not the case anyway? In a large, scalable architecture, your database server should be independent of the web server/garden/farm on which the application is deployed, and the database server itself can be clustered to provide redundancy... and it can exist in a master/replica schema as well, but in the end, there's your data in that database, and if it fails, you're hosed. On the other hand, you could simply use Active Directory, if you're willing to learn how to use ADSI -- 'cause why re-invent the wheel? jon.vickers wrote: efficient and secure way to transfer users from one application to the other application without having to relogin This sounds like sharing state between ASP and ASP.NET applications. There's one example here[^] and Google will yield about 42,000 more. ;) jon.vickers wrote: ASP.Net Form authentication can work across multiple apps You can store session state on a server designated to retain state or in a designated database server; also, place other applications in the same directory structure, so that each application inherits its parent's web.config, or overrides when necessary. What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.
Thanks John, "I don't want all my of my applications tied to one database." Right now each application has its own database on its own db server. So even if I loose a db server we loose one application. The problem I am worried about is tieing 3-4 applications to one central db that could cause all applications to fail. Forms Authentication: I understand that if you setup the machine.config flies correctly they can share the authentication cookie. How does this work if the applications are running under seperate domains? The browser will not send the cookie to another domain, right? I am leaning towards creating some sort of web service that each application will call to authenticate the user. Encapsulating this in a try/catch block. If the web service does not respond I will check the local applications login table and use the last known good credentials, how does that sound? Does anyone have any examples of transfering an authenticated users from Application A on domain A to application B on domain B, possibly on a seperate server. I assume there will have to be some sort of token transferred from one db to another, then transfer the user to application B, then destroy the token once the users arrives. Does anyone have any input on this concept. Thanks, Jon Vickers
-
Thanks John, "I don't want all my of my applications tied to one database." Right now each application has its own database on its own db server. So even if I loose a db server we loose one application. The problem I am worried about is tieing 3-4 applications to one central db that could cause all applications to fail. Forms Authentication: I understand that if you setup the machine.config flies correctly they can share the authentication cookie. How does this work if the applications are running under seperate domains? The browser will not send the cookie to another domain, right? I am leaning towards creating some sort of web service that each application will call to authenticate the user. Encapsulating this in a try/catch block. If the web service does not respond I will check the local applications login table and use the last known good credentials, how does that sound? Does anyone have any examples of transfering an authenticated users from Application A on domain A to application B on domain B, possibly on a seperate server. I assume there will have to be some sort of token transferred from one db to another, then transfer the user to application B, then destroy the token once the users arrives. Does anyone have any input on this concept. Thanks, Jon Vickers
jon.vickers wrote: The problem I am worried about is tieing 3-4 applications to one central db that could cause all applications to fail. Right, that's where the hardware & server system architecture becomes critical; i think you could build a db server that would be pretty darn bullet-proof. jon.vickers wrote: The browser will not send the cookie to another domain, right? I don't think so, not without something you build from scratch. Given the choice between building a web service and building a component, I'd build a component and register it in the GAC, the performance will be much better and much more scalable than a web service. jon.vickers wrote: transfering an authenticated users from Application A on domain A to application B on domain B The only thing I can think of (with my little brain) is to stick a name/value pair in a query string and then hash the query string and retrieve it and un-hash it in application B. What a piece of work is man, how noble in reason, how infinite in faculties, in form and moving how express and admirable . . . and yet to me, what is this quintessence of dust? -- Hamlet, Act II, Scene ii.