The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Issue with a login Interface design

I'm having some problems working with a simple interface design.

Since I have a lots of applications which requires login/logout, rolls/permissions functionalities,
I thought I could abstract some of those functionalities to reuse them in any new project.

I started with the user interface which I defined like this:

interface IUser
{
double ID { get; set; }
string name { get; set; }
}

Then I made a login interface, since not every user needs to login:

interface ILogin
{
 bool login(string name, byte[] password);
}

Every applications has his own kind of users (administrator, read-only user, etc...).
Each of them would represent a particular class that implements IUser and/or ILogin.

The part I'm missing is the following. When a user logs into the system, which is the login method I should call?
Do I need an abstract user class with a login method inside? How will I know what kind of user just logged in?

I tried to look for a design pattern that I could use but I haven't found anything yet.

Anyone?
Jérôme De Cuyper Send private email
Tuesday, July 15, 2008
 
 
The "Login" method should be implemented by a "Security Provider" not a "User".
hobit Send private email
Tuesday, July 15, 2008
 
 
Most platforms will have a preferred way of doing this.  In .Net, for instance, you'd want to look at IPrincipal and IIdentity interfaces to build a custom authentication provider.  I'd say your best bet is to try and find a reference architecture for your platform of choice and see how it's handled there.  It might save you a fair bit of work (or rework).
D. Lambert Send private email
Tuesday, July 15, 2008
 
 
>> I'd say your best bet is to try and find a
>> reference architecture for your platform of
>> choice and see how it's handled there.  It might
>> save you a fair bit of work (or rework).

I'd go one farther than D. Lambert's excellent advice: not only will you save time, but rolling your own will probably be *LESS* secure than what your platform has already implemented.
Micah Tan Send private email
Tuesday, July 15, 2008
 
 
You may look into open frameworks like OpenID or InfoCard from microsoft.There are tons of identity management, and security implmentations, The real problem with making your own is that the ability to allow "Single Sign On" for your apps works great, but it won't interoperate very well.

Looking at microsoft, they have 3 modes of authentication
NTLM, Kerberos, and then Passport/LiveID
that is what logins provide, then you look at the Authorization side there is a whole other can of worms.

Looking at user-stores in microsoft products you have
SQL accounts, Sharepoint account, AD account, MSCrm has their own, and then pick any other LOB application, one tool we used to synch these was called Oblix, which suprisingly Oracle purchased.

The real deal coming out soon from MS will be the next generation Federation Services, currently there was a release of Zermatt, a claims based auth/auth (probably authentication) framework .

Good Luck
Lucas Send private email
Tuesday, July 15, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz