public vs private access: implement two interfaces in same object?

public vs private access: implement two interfaces in same object?

Post by Richard Reitmeye » Fri, 11 Aug 2000 04:00:00



I've got a problem where I need two different access levels to the same
object.

Debit_Card provides the card number to anyone who asks, but only the
Bank is allowed to make calls to the get_PIN() method, so only it can
validate people's PINs.

I was happily doing this via a CORBA interface that had no notion of
get_PIN, and relying on the Bank having an _impl * to the actual object.

This suddenly works less well if I move to Servant Locators using LRU
evictor queues; the Debit_Card object might well get flushed to disk in
the middle of a bank operation.  (In this simple example I could make
the bank be the Servant Locator for Debit Cards, but that scales poorly
when I have a second object needing that _impl * access.)

I'm tempted to go down the route of:

interface Public_Debit_Card {
    string get_number();

Quote:};

interface Private_Debit_Card {
    string get_PIN();

Quote:};

class Debit_Card_impl : public virtual Public_Debit_Card, public virtual
Private_Debit_Card {
   //  ...

Quote:};

But this raises the obvious questions:

1) Will this work at all?
2)  If I called ->this() on a Debit_Card_impl, what would I get?

If I'm the Bank object, and I have a Public_Debit_Card_ptr, and want the
PIN, I must get some UID for the card, and call off to the servant
locator to hand back the Private_Debit_Card_ptr for the card with the
given UID.  Performace-wise, that honks.

How do other people deal with this stuff?

Richard

 
 
 

public vs private access: implement two interfaces in same object?

Post by Stefan Seefel » Fri, 11 Aug 2000 04:00:00



> I'm tempted to go down the route of:

> interface Public_Debit_Card {
>     string get_number();
> };

> interface Private_Debit_Card {
>     string get_PIN();
> };

> class Debit_Card_impl : public virtual Public_Debit_Card, public virtual
> Private_Debit_Card {
>    //  ...
> };

> But this raises the obvious questions:

> 1) Will this work at all?

no, as we discussed in a different thread.

Quote:> 2)  If I called ->this() on a Debit_Card_impl, what would I get?

that's part of the problem.

what about this instead:

interface PublicCard
{
   long number();

Quote:};

interface PrivateCard : PublicPart
{
   long pin();

Quote:};

interface Bank;

interface Person
{
   readonly attribute PublicCard card;
   void pay(Bank);

Quote:};

interface Bank
{
   void check(PrivateCard);

Quote:};

and then in the implementation:

class CardImpl : public virtual POA_PrivateCard {};

class PersonImpl
{
  PublicCard_ptr card() { return mycard->_this();}
  void pay(Bank_ptr bank) { bank->check(PrivateCard_var(mycard->_this()));}
private:
  CardImpl *mycard;

Quote:};

The trick is that 'person' is in control of who sees the private parts
of the card. It hands over the details to the bank, but a stranger can
only ask for the public part of it.

Regards,        Stefan
_______________________________________________________              

Stefan Seefeld
Departement de Physique
Universite de Montreal

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...

 
 
 

public vs private access: implement two interfaces in same object?

Post by Robert O'Dow » Sat, 12 Aug 2000 04:00:00



> I've got a problem where I need two different access levels to the same
> object.

> Debit_Card provides the card number to anyone who asks, but only the
> Bank is allowed to make calls to the get_PIN() method, so only it can
> validate people's PINs.

> I was happily doing this via a CORBA interface that had no notion of
> get_PIN, and relying on the Bank having an _impl * to the actual object.

> This suddenly works less well if I move to Servant Locators using LRU
> evictor queues; the Debit_Card object might well get flushed to disk in
> the middle of a bank operation.  (In this simple example I could make
> the bank be the Servant Locator for Debit Cards, but that scales poorly
> when I have a second object needing that _impl * access.)

> I'm tempted to go down the route of:

> interface Public_Debit_Card {
>     string get_number();
> };

> interface Private_Debit_Card {
>     string get_PIN();
> };

> class Debit_Card_impl : public virtual Public_Debit_Card, public virtual
> Private_Debit_Card {

I assume you mean

class Debit_Card_impl : public virtual POA_Public_Debit_Card, public
virtual
POA_Private_Debit_Card

The results of doing this are unspecified.

Quote:>    //  ...
> };

> But this raises the obvious questions:

> 1) Will this work at all?

No.

Quote:> 2)  If I called ->this() on a Debit_Card_impl, what would I get?

That is undefined by CORBA.  The results really depend on how your
ORB implements the _this() method, and probably on how remote
invocations are passed to your servant methods.  It is quite
possible such a thing will not even compile (eg in C++ the
call to _this() would probably be ambiguous).

Quote:

> If I'm the Bank object, and I have a Public_Debit_Card_ptr, and want the
> PIN, I must get some UID for the card, and call off to the servant
> locator to hand back the Private_Debit_Card_ptr for the card with the
> given UID.  Performace-wise, that honks.

> How do other people deal with this stuff?

Probably by not exposing the PIN through a credit card
interface at all.  A key weakness of allowing other objects
(even a Bank) access to a security token like a PIN is that your
complete security system then depends on the good graces
of those objects.

A better approach probably goes something like....

exception InvalidAccess {};

interface CreditCard
{
     boolean CheckPin(in string pin) raises(InvalidAccess);

     void SetPin(in string oldpin, in string newpin) raises
(InvalidAccess);

     Currency GetBalance() raises (InvalidAccess);

     void Withdraw(in Currency amount) raises (InvalidAccess,
InsufficentFunds);

       // etc

     void Deactivate() raises (InvalidAccess);

Quote:};

This allows any client (even a bank) to have a PIN checked, but provides
no means of reading the current PIN.  It also requires the current PIN
to be
supplied before the PIN can be altered.  So, a client must *know* the
PIN before they can do anything significant.

The implementation of CheckPin can simply enforce a limit
on the number of times it is called with an invalid PIN before it
deactivates the credit card (eg after three invalid tries, the card
is deactivated for all clients).  Other methods can also enforce
various levels of security (eg throw an exception if a certain
time has passed since a valid PIN was given).

Of course, there is still an authentication issue of ensuring the
client that provides a valid PIN is the same one that tries
to complete transactions on the credit card.