Hi there. I am developing a custom authentication and sessions implementation that does not derive from the default providers in any way whatsoever. The default providers for authentication, roles, membership and session state are all disabled so to ensure
the application ONLY uses my code and modules for these types of functionality. So far everything is running great with the session module and now I am working on the authentication portion.
For authentication I also have to customized classes, one implementing IPrincipal and the other IIdentity. The classes properly provide suppport for their given interface but I have one question regarding the one that inherits from IIdentity.
The public property "string AuthenticationType" has me a little stumped. Do I need to provide a valid Authentication type for this value in its implementation? I ask because like I said, my code handles all of its implementation its self and does not make
use of any default providers, nor does it derive or extend them. I guess what I'm asking is do I have to provide a default value for this even if Im not using any provider for the authentication or can I just return a dummy string? I don't know if this property
will still be called by the runtime even though the authentication mode is set to "none" in my root config.
When the going get's tough, the tough outsource and take a vacation... lol I wish :(
Yea, it's just meant to be an identifier for how authentication was performed -- so how are you authenticating? If it's something custom, then give your scheme a name. If you're using Forms but just overwriting the IIdentity with a custom one then maybe
keep it "Forms". This value isn't used anywhere by the plumbing, so it's really just for display/diagnostics.
magicmike201...
Contributor
2021 Points
481 Posts
Question about System.Security.Principal.IIdentity custom implementation
Jun 29, 2012 08:03 PM|LINK
Hi there. I am developing a custom authentication and sessions implementation that does not derive from the default providers in any way whatsoever. The default providers for authentication, roles, membership and session state are all disabled so to ensure the application ONLY uses my code and modules for these types of functionality. So far everything is running great with the session module and now I am working on the authentication portion.
For authentication I also have to customized classes, one implementing IPrincipal and the other IIdentity. The classes properly provide suppport for their given interface but I have one question regarding the one that inherits from IIdentity.
The public property "string AuthenticationType" has me a little stumped. Do I need to provide a valid Authentication type for this value in its implementation? I ask because like I said, my code handles all of its implementation its self and does not make use of any default providers, nor does it derive or extend them. I guess what I'm asking is do I have to provide a default value for this even if Im not using any provider for the authentication or can I just return a dummy string? I don't know if this property will still be called by the runtime even though the authentication mode is set to "none" in my root config.
BrockAllen
All-Star
28072 Points
4996 Posts
MVP
Re: Question about System.Security.Principal.IIdentity custom implementation
Jun 29, 2012 09:28 PM|LINK
Yea, it's just meant to be an identifier for how authentication was performed -- so how are you authenticating? If it's something custom, then give your scheme a name. If you're using Forms but just overwriting the IIdentity with a custom one then maybe keep it "Forms". This value isn't used anywhere by the plumbing, so it's really just for display/diagnostics.
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
magicmike201...
Contributor
2021 Points
481 Posts
Re: Question about System.Security.Principal.IIdentity custom implementation
Jun 29, 2012 09:58 PM|LINK
Thank you Brock, that was exactly what I needed to know. I guess I should keep some sort of meaningful value in there for logging purposes maybe then.