Deleteing consumers and certs

[Adam Young]

I should have posted to this list insted of imanage.  Sorry for the dup 
postings, but I realized that I wouldn't get responses from the other list.

Right now there is a one to one relationship between consumer and 
certificate.  THe id for the ConsumerIdentityCertificate is the same as 
the ID for the consumer.  Thus, if we delete the consumer, we should 
delete the certificate.

Is this sufficient for revoke?

Part of me thinks that we should never throw away data:  once we record 
a consumer, we should keep that information and just transform it into a 
"inactive" state, but I realize that complicates the logic, and 
potentially has an impact on Database size and performance.

[Devan Goodwin]

On Wed, Mar 10, 2010 at 9:51 PM, Adam Young  wrote:
> I should have posted to this list insted of imanage.  Sorry for the dup
> postings, but I realized that I wouldn't get responses from the other list.
>
> Right now there is a one to one relationship between consumer and
> certificate.  THe id for the ConsumerIdentityCertificate is the same as
> the ID for the consumer.  Thus, if we delete the consumer, we should
> delete the certificate.
>
> Is this sufficient for revoke?
>
> Part of me thinks that we should never throw away data:  once we record
> a consumer, we should keep that information and just transform it into a
> "inactive" state, but I realize that complicates the logic, and
> potentially has an impact on Database size and performance.

Deleting the cert sounds ok to me.

I'm not sure but I think in our case we don't even need to worry about
revoking them, all we really need certs for is to verify we're talking
to the consumer we think we are. If that consumer has been deleted but
it's still trying to communicate with us, we'll pull the UUID out of
their un-revoked cert, and try to use it in the db, which will fail
fast and hard.

Cheers,

Devan

[Bryan Kearney]

On 03/10/2010 09:42 PM, Devan Goodwin wrote:
> On Wed, Mar 10, 2010 at 9:51 PM, Adam Young  wrote:
> > I should have posted to this list insted of imanage.  Sorry for the dup
> > postings, but I realized that I wouldn't get responses from the other list.
> >
> > Right now there is a one to one relationship between consumer and
> > certificate.  THe id for the ConsumerIdentityCertificate is the same as
> > the ID for the consumer.  Thus, if we delete the consumer, we should
> > delete the certificate.
> >
> > Is this sufficient for revoke?

I would like to make sure we call the service so that if there is some 
future revocation, that we actually do it.
> > Part of me thinks that we should never throw away data:  once we record
> > a consumer, we should keep that information and just transform it into a
> > "inactive" state, but I realize that complicates the logic, and
> > potentially has an impact on Database size and performance.

So.. would deactivate be a POST to /consumers/uuid

?

and delete be a real delete?

--b k

[Adam Young]

On 03/11/2010 08:48 AM, Bryan Kearney wrote:
> On 03/10/2010 09:42 PM, Devan Goodwin wrote:
> > On Wed, Mar 10, 2010 at 9:51 PM, Adam Young   wrote:
> > > I should have posted to this list insted of imanage.  Sorry for the dup
> > > postings, but I realized that I wouldn't get responses from the other list.
> > >
> > > Right now there is a one to one relationship between consumer and
> > > certificate.  THe id for the ConsumerIdentityCertificate is the same as
> > > the ID for the consumer.  Thus, if we delete the consumer, we should
> > > delete the certificate.
> > >
> > > Is this sufficient for revoke?
>
> I would like to make sure we call the service so that if there is some
> future revocation, that we actually do it.

I was planning on having the delete of the consumer call a corresponding 
delete of the cert.  I'm unclear what having a separate service call 
would do.
> > > Part of me thinks that we should never throw away data:  once we record
> > > a consumer, we should keep that information and just transform it into a
> > > "inactive" state, but I realize that complicates the logic, and
> > > potentially has an impact on Database size and performance.
>
> So.. would deactivate be a POST to /consumers/uuid
>
> ?
>
> and delete be a real delete?

If we go that way, yes.  I'm not suggesting we do.

What is the requirement?  WHat is the feature that needs to be 
implemented here? That we have a way to "shut off" access to  consumer 
after a given point in time?  If so, are there any other requirments, 
along the lines of reporting and audit, or reactivation of consuemrs 
that we need to take into account.  If not, is there any reason the cert 
can't just go into the consumer object and be done with it, as that is 
the simplest implementation.
> --b k
> _______________________________________________
> candlepin mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/candlepin