Interface question

[tshad]

I am trying to understand why I would use interfaces.

In the following example for IPrinciple, I have the following code:

************************************************************
using System;
using System.Collections;
using System.Security;
using System.Security.Principal;

namespace CustomSecurity
{
[Serializable]
public class CustomPrincipal: IPrincipal
{
private IIdentity identity;
private ArrayList roles;

public CustomPrincipal(IIdentity id, ArrayList rolesArray)
{
identity = id;
roles = rolesArray;
}
public bool IsInRole(string role)
{
return roles.Contains( role );
}

public IIdentity Identity
{
get { return identity; }
set { identity = value; }
}
}
}
*****************************************************

I understand that IPrincipal (and IIdentity) is defined as:

*********************************************************
namespace System.Security.Principal {
interface IIdentity {
bool IsAuthenticated { get; }
string AuthenticationType { get; }
string Name { get; }
}
interface IPrincipal {
IIdentity Identity { get; }
bool IsInRole(string role);
}
}
**********************************************************

What would be the difference if I just wrote the code as (I understand that
I also would have the IIdentity class also).:

**********************************************************
using System;
using System.Collections;
using System.Security;

namespace CustomSecurity
{
[Serializable]
public class CustomPrincipal
{
private IIdentity identity;
private ArrayList roles;

public CustomPrincipal(IIdentity id, ArrayList rolesArray)
{
identity = id;
roles = rolesArray;
}
public bool IsInRole(string role)
{
return roles.Contains( role );
}

public IIdentity Identity
{
get { return identity; }
set { identity = value; }
}
}
}
*****************************************************

Does the system handle it any different?

Thanks,

Tom

 

[David Hogue]

Implementing the IPrinciple interface won't have any affect on how your
CustomPrincipal class behaves.

The difference is if you have a function that requires an argument of
type IPrincipal (sorry I don't have an example handy). You would be
able to pass an instance of your first CustomPrincipal in to that
function, but the second would generate a compiler error since it's not
the right type.

It's kinda late, so I hope that made sense.

I am trying to understand why I would use interfaces.

In the following example for IPrinciple, I have the following code:

************************************************************
using System;
using System.Collections;
using System.Security;
using System.Security.Principal;

namespace CustomSecurity
{
[Serializable]
public class CustomPrincipal: IPrincipal
{
private IIdentity identity;
private ArrayList roles;

public CustomPrincipal(IIdentity id, ArrayList rolesArray)
{
identity = id;
roles = rolesArray;
}
public bool IsInRole(string role)
{
return roles.Contains( role );
}

public IIdentity Identity
{
get { return identity; }
set { identity = value; }
}
}
}
*****************************************************

I understand that IPrincipal (and IIdentity) is defined as:

*********************************************************
namespace System.Security.Principal {
interface IIdentity {
bool IsAuthenticated { get; }
string AuthenticationType { get; }
string Name { get; }
}
interface IPrincipal {
IIdentity Identity { get; }
bool IsInRole(string role);
}
}
**********************************************************

What would be the difference if I just wrote the code as (I understand that
I also would have the IIdentity class also).:

**********************************************************
using System;
using System.Collections;
using System.Security;

namespace CustomSecurity
{
[Serializable]
public class CustomPrincipal
{
private IIdentity identity;
private ArrayList roles;

public CustomPrincipal(IIdentity id, ArrayList rolesArray)
{
identity = id;
roles = rolesArray;
}
public bool IsInRole(string role)
{
return roles.Contains( role );
}

public IIdentity Identity
{
get { return identity; }
set { identity = value; }
}
}
}
*****************************************************

Does the system handle it any different?

Thanks,

Tom

 

[tshad]

Implementing the IPrinciple interface won't have any affect on how your
CustomPrincipal class behaves.

The difference is if you have a function that requires an argument of
type IPrincipal (sorry I don't have an example handy). You would be
able to pass an instance of your first CustomPrincipal in to that
function, but the second would generate a compiler error since it's not
the right type.

Is that the main reason? Other than setting up security, why would I need
IPrincipal and IIdentity?

I am not trying to NOT use it. I am just trying to find out why it is
better than the identical code, without the IPrincipal inheritance.

I assume that the windows Authorization, such as Forms, doesn't need it. I
mean does windows (IIS) look for IPrincipal and IIdentity when it is using
managed security context?

Also, is CustomPrincipal of type IPrincipal just because it inherits from it
(maybe I am getting inheritance confused with interfaces).

I am trying to see all the reasons why to use interfaces.

Thanks,

Tom

It's kinda late, so I hope that made sense.

I am trying to understand why I would use interfaces.

In the following example for IPrinciple, I have the following code:

************************************************************
using System;
using System.Collections;
using System.Security;
using System.Security.Principal;

namespace CustomSecurity
{
[Serializable]
public class CustomPrincipal: IPrincipal
{
private IIdentity identity;
private ArrayList roles;

public CustomPrincipal(IIdentity id, ArrayList rolesArray)
{
identity = id;
roles = rolesArray;
}
public bool IsInRole(string role)
{
return roles.Contains( role );
}

public IIdentity Identity
{
get { return identity; }
set { identity = value; }
}
}
}
*****************************************************

I understand that IPrincipal (and IIdentity) is defined as:

*********************************************************
namespace System.Security.Principal {
interface IIdentity {
bool IsAuthenticated { get; }
string AuthenticationType { get; }
string Name { get; }
}
interface IPrincipal {
IIdentity Identity { get; }
bool IsInRole(string role);
}
}
**********************************************************

What would be the difference if I just wrote the code as (I understand that
I also would have the IIdentity class also).:

**********************************************************
using System;
using System.Collections;
using System.Security;

namespace CustomSecurity
{
[Serializable]
public class CustomPrincipal
{
private IIdentity identity;
private ArrayList roles;

public CustomPrincipal(IIdentity id, ArrayList rolesArray)
{
identity = id;
roles = rolesArray;
}
public bool IsInRole(string role)
{
return roles.Contains( role );
}

public IIdentity Identity
{
get { return identity; }
set { identity = value; }
}
}
}
*****************************************************

Does the system handle it any different?

Thanks,

Tom

 

[David Hogue]

Is that the main reason? Other than setting up security, why would I need
IPrincipal and IIdentity?

My understanding of IPrincipal and IIdentity isn't the best, but I
believe they are used primarily for security. Setting user roles and
that kind of thing.

I am not trying to NOT use it. I am just trying to find out why it is
better than the identical code, without the IPrincipal inheritance.

It's only better if you need treat the class as an IPrincipal.

I assume that the windows Authorization, such as Forms, doesn't need it. I
mean does windows (IIS) look for IPrincipal and IIdentity when it is using
managed security context?

Windows and Forms based authentication both use the interfaces, but you
don't need to interact with them directly unless you want to change
default behavior.

For example: The company I work for has a system with users and roles
stored in a database. When a request is authenticated we get a list of
roles and create a GenericPrincipal (GenericPrincipal implements
IPrincipal):

string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
Context.User = new GenericPrincipal(Context.User.Identity, userRoles);

Though we didn't use a custom principal class we could have and it might
look something like this:

public class SmartzPrincipal : IPrincipal
{
private IIdentity identity;
public SmartzPrincipal(IIdentity identity)
{
this.identity = identity;
}

public IIdentity Identity
{
get { return identity; }
}

public IsInRoles(String role)
{
List<string> roles = db.GetUserRoles(identity.Name);
return roles.Contains(role);
}
}

Then we would use it like so:

Context.User = new SmartzPrincipal(Context.User.Identity);

While the version with the interface looks longer in my example it would
actually be simpler than what we have. It would encapsulate all the
role based code in one place and be more reusable.

Also, is CustomPrincipal of type IPrincipal just because it inherits from it
(maybe I am getting inheritance confused with interfaces).

Implements is the word I hear most often when referring to interfaces.
It's really the same concept as inheriting from a base class, except you
can implement multiple interfaces and only inherit from one base class.

CustomPrincipal is of type IPrincipal because it implements it.

I am trying to see all the reasons why to use interfaces.

Thanks,

Tom

I hope I'm helping and not just confusing things...

 

[tshad]

My understanding of IPrincipal and IIdentity isn't the best, but I
believe they are used primarily for security. Setting user roles and
that kind of thing.


It's only better if you need treat the class as an IPrincipal.


Windows and Forms based authentication both use the interfaces, but you
don't need to interact with them directly unless you want to change
default behavior.

For example: The company I work for has a system with users and roles
stored in a database. When a request is authenticated we get a list of
roles and create a GenericPrincipal (GenericPrincipal implements
IPrincipal):

That is what I am curious about.

When you talk about users and roles stored in a database, are you talking
about Windows Users and Roles (User Policies)?

I assume you can't use the GenericPrincipal to handle your own users and
roles, such as office managers and their roles. These would be stored in
your own database and the GenericPrincipal wouldn't know about that.

string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
Context.User = new GenericPrincipal(Context.User.Identity, userRoles);

Though we didn't use a custom principal class we could have and it might
look something like this:

If you didn't use a custom principal class, I assume you don't store your
own users, roles a policies, right?

public class SmartzPrincipal : IPrincipal
{
private IIdentity identity;
public SmartzPrincipal(IIdentity identity)
{
this.identity = identity;
}

public IIdentity Identity
{
get { return identity; }
}

public IsInRoles(String role)
{
List<string> roles = db.GetUserRoles(identity.Name);
return roles.Contains(role);
}
}

Then we would use it like so:

Context.User = new SmartzPrincipal(Context.User.Identity);

While the version with the interface looks longer in my example it would
actually be simpler than what we have. It would encapsulate all the
role based code in one place and be more reusable.


Implements is the word I hear most often when referring to interfaces.
It's really the same concept as inheriting from a base class, except you
can implement multiple interfaces and only inherit from one base class.

CustomPrincipal is of type IPrincipal because it implements it.


I hope I'm helping and not just confusing things...

You are. I am just trying to really understand it. I sort of understand
interfaces, but am trying to find the reasons to use them vs when not to use
them. Just because you can doesn't mean you should (in all cases).

Thanks,

Tom

 

[David Hogue]

That is what I am curious about.

When you talk about users and roles stored in a database, are you talking
about Windows Users and Roles (User Policies)?

I assume you can't use the GenericPrincipal to handle your own users and
roles, such as office managers and their roles. These would be stored in
your own database and the GenericPrincipal wouldn't know about that.

We can (and did) use GenericPrincipal to handle our own users and roles.
This is because it is a "generic", for lack of a better term,
implementation of the IPrincipal interface. We can give a
GenericPrincipal an array of strings and it will return true from the
IsInRoles method if that role is in the array.

We did't have to create our own class that implemented IPrincipal,
GenericPrincipal was already there for us. However the downside is that
the code to get the users from the database still has to go somewhere
and it ended up mixed in with a bunch of unrelated code.

string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
Context.User = new GenericPrincipal(Context.User.Identity, userRoles);

Though we didn't use a custom principal class we could have and it might
look something like this:

If you didn't use a custom principal class, I assume you don't store your
own users, roles a policies, right?

public class SmartzPrincipal : IPrincipal
{
private IIdentity identity;
public SmartzPrincipal(IIdentity identity)
{
this.identity = identity;
}

public IIdentity Identity
{
get { return identity; }
}

public IsInRoles(String role)
{
List<string> roles = db.GetUserRoles(identity.Name);
return roles.Contains(role);
}
}

Then we would use it like so:

Context.User = new SmartzPrincipal(Context.User.Identity);

While the version with the interface looks longer in my example it would
actually be simpler than what we have. It would encapsulate all the
role based code in one place and be more reusable.

Implements is the word I hear most often when referring to interfaces.
It's really the same concept as inheriting from a base class, except you
can implement multiple interfaces and only inherit from one base class.

CustomPrincipal is of type IPrincipal because it implements it.

I hope I'm helping and not just confusing things...

You are. I am just trying to really understand it. I sort of understand
interfaces, but am trying to find the reasons to use them vs when not to use
them. Just because you can doesn't mean you should (in all cases).

Interfaces and some of the more abstract object oriented ideas can be
difficult to fully understand. I've been working with object oriented
languages for years, but it's only relatively recently that my code has
become more object oriented.

I would suggest reading up on design patterns for some insight into how
interfaces are often used. There was a recent article on codebetter.com
that might be a good place to start:
http://codebetter.com/blogs/jeremy.miller/archive/2006/04/11/142665.aspx

 

[Patrick.O.Ige]

David very good links there
Patrick

That is what I am curious about.

When you talk about users and roles stored in a database, are you talking
about Windows Users and Roles (User Policies)?

I assume you can't use the GenericPrincipal to handle your own users and
roles, such as office managers and their roles. These would be stored in
your own database and the GenericPrincipal wouldn't know about that.

We can (and did) use GenericPrincipal to handle our own users and roles.
This is because it is a "generic", for lack of a better term,
implementation of the IPrincipal interface. We can give a
GenericPrincipal an array of strings and it will return true from the
IsInRoles method if that role is in the array.

We did't have to create our own class that implemented IPrincipal,
GenericPrincipal was already there for us. However the downside is that
the code to get the users from the database still has to go somewhere
and it ended up mixed in with a bunch of unrelated code.

string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
Context.User = new GenericPrincipal(Context.User.Identity, userRoles);

Though we didn't use a custom principal class we could have and it might
look something like this:

If you didn't use a custom principal class, I assume you don't store your
own users, roles a policies, right?

public class SmartzPrincipal : IPrincipal
{
private IIdentity identity;
public SmartzPrincipal(IIdentity identity)
{
this.identity = identity;
}

public IIdentity Identity
{
get { return identity; }
}

public IsInRoles(String role)
{
List<string> roles = db.GetUserRoles(identity.Name);
return roles.Contains(role);
}
}

Then we would use it like so:

Context.User = new SmartzPrincipal(Context.User.Identity);

While the version with the interface looks longer in my example it would
actually be simpler than what we have. It would encapsulate all the
role based code in one place and be more reusable.

Also, is CustomPrincipal of type IPrincipal just because it inherits
from
it
(maybe I am getting inheritance confused with interfaces).
Implements is the word I hear most often when referring to interfaces.
It's really the same concept as inheriting from a base class, except you
can implement multiple interfaces and only inherit from one base class.

CustomPrincipal is of type IPrincipal because it implements it.

I am trying to see all the reasons why to use interfaces.

Thanks,

Tom
I hope I'm helping and not just confusing things...

You are. I am just trying to really understand it. I sort of understand
interfaces, but am trying to find the reasons to use them vs when not to
use
them. Just because you can doesn't mean you should (in all cases).

Interfaces and some of the more abstract object oriented ideas can be
difficult to fully understand. I've been working with object oriented
languages for years, but it's only relatively recently that my code has
become more object oriented.

I would suggest reading up on design patterns for some insight into how
interfaces are often used. There was a recent article on codebetter.com
that might be a good place to start:
http://codebetter.com/blogs/jeremy.miller/archive/2006/04/11/142665.aspx

 

[tshad]

That is what I am curious about.

When you talk about users and roles stored in a database, are you talking
about Windows Users and Roles (User Policies)?

I assume you can't use the GenericPrincipal to handle your own users and
roles, such as office managers and their roles. These would be stored in
your own database and the GenericPrincipal wouldn't know about that.

We can (and did) use GenericPrincipal to handle our own users and roles.
This is because it is a "generic", for lack of a better term,
implementation of the IPrincipal interface. We can give a
GenericPrincipal an array of strings and it will return true from the
IsInRoles method if that role is in the array.

We did't have to create our own class that implemented IPrincipal,
GenericPrincipal was already there for us. However the downside is that
the code to get the users from the database still has to go somewhere
and it ended up mixed in with a bunch of unrelated code.

string[] userRoles = db.GetUserRoles(Context.User.Identity.Name);
Context.User = new GenericPrincipal(Context.User.Identity, userRoles);

I assume that if you use the GenericPrincipal, you need to use it as is and
if you want to add anything else (another method, some special test, read
from your user table etc) , you would need to create another class (as you
did below with SmartzPrincipal).

This is my question.

If you created your SmartzPrincipal and you used all the methods defined in
IPrincipal, why use IPrincipal at all?

What does it do for you? That's what I am trying to get my mind around.

Interfaces and some of the more abstract object oriented ideas can be
difficult to fully understand. I've been working with object oriented
languages for years, but it's only relatively recently that my code has
become more object oriented.

I would suggest reading up on design patterns for some insight into how
interfaces are often used. There was a recent article on codebetter.com
that might be a good place to start:
http://codebetter.com/blogs/jeremy.miller/archive/2006/04/11/142665.aspx

Looks like a great article.

Will look at it later today.

Thanks,

Tom