If certificates are public anyways, why are they stored in a password-protected keystore?
Is this a must, or a means to relate the public key to the private key?
There a few reasons for that:
First, in terms of implementation it is indeed a means to relate a private key to a public key. If a private key if compromised, the whole certificate is compromised.
Second,
the knowledge of "who we trust" is valuable.
Third,
a random user shouldn't be able to add new certificates to the trust store.
Related
I'm working on an application whose data model is intentionally fragmented so that only certain bits of the data model are ever loaded into memory at a given time. Let's say for the sake of argument, I'm building a banking application where the data model looks like:
Bank
id
name
SecurityKey
password
security phrase
Vault
value (String)
Using this model, each bank has exactly one security key and one vault associated with it. In order to unlock a vault, a user has to enter their password and answer their security question at which one, the corresponding vault is loaded from disk and the secret information is displayed to the user. The data model is designed this way so that when just looking at banks, they don't have a reference to the key or the vault and this way, those children objects can be loaded on demand and kept separate from the parent object.
Of course there does have to be some sort of back-reference from the child to parent so my thought was to add a property to SecurityKey and Vault called bankId of type String that points to the parent bank rather than having a CoreData relationship that enforces an inverse relationship, which entirely defeats the purpose of not having a direct relationship to the child so it can't be easily accessed. I could also define a relationship on SecurityKey and Vault that points to the bank and disable the inverse relationship warnings in my settings but that seems dangerous.
I have several questions around my approach and best practices for CoreData:
Is a data model like this even necessary? If the bank has references to the key and the vault and they're all loaded into memory, does that matter? If someone is able to extract those values from memory, that's a security problem well outside my purview. (I also want to keep them separate so that I can ensure that I don't accidentally log sensitive information to the console i.e. by printing a bank, the vault doesn't also get printed).
What are the disadvantages to not using an inverse relationship? I understand that those relationships are how core data ensures data integrity and are important in things such as cascading deletes. If I don't utilize inverse relationships, when deleting a bank, I would also have to make sure the associated key and vault are also cleaned up as well as checking on app launch for any possibly orphaned objects that result from a failed core data transaction.
If it is in fact important to keep the models separate, which would serve me better, a simple id pointing back to the bank or a full-blown CoreData relationship?
It seems to me that almost by default all code first POCO's should have private setters for their primary key a.k.a. auto-generated Id.
Like this -
public int id { get; private set; }
Is this an incorrect assumption? I do not want my API to allow setting of an auto-generated column.
Exposing a public setter should not be an issue since it is unadvised to even expose this POCO outside the Data Access Object layer..
Exposing a POCO decorated with a specific framework's attributes, or even a POCO which discloses some kind of information regarding storage (Entity Relational Database, in this instance) is a bad practice.
Consider wrapping it in an interface and returning it as an instance of that interface. This way you get to enjoy the best of both worlds. Exposing the properties which are necessary and allowing to set only a part of them.
In any case, I do not think that EF will like the private setter thing too much.
I am creating a kind of social network and I have users that can follow other users. So I have an entity like:
#Entity
public class FollowedUser{
#ManyToOne
private User user;
#ManyToOne
private User followedUser;
//more fields
...
}
I cannot have a ManyToMany relationship as I have more fields in my FollowedUser entity. Now, the questions I have are:
Should I use a compound key or a generated id (surrogate key)? I have read the following links (1, 2, 3) about the topic where a surrogate key is suggested, but I don't know if they apply to my concrete case (where my compound key would be composed of two surrogate foreign keys). Also here (4) it says "Composite primary keys typically arise when mapping from legacy databases" so I suppose they are discouraged.
In case I should use a compound key, I don't know if I should use #IdClass (as recommended here 5) or #EmbeddedId (as recommended here 6) or any other option. Although I suppose it doesn't matter.
In case I should use a surrogate key, I don't know how to still make impossible to have the compound candidate key repeated. I have read here (7) about unique indexes but I don't know if it is the correct workaround to that problem.
1. I recommend using surrogate keys. I find it helpful to separate the database identity of a record from it's business identity. If the two concepts are mixed, it may be cumbersome to model them right and to remodel them later. You reference some good answers, so you are probably aware of the major up- and downsides, no need to reiterate them here. One additional point is that you can rely on the surrogate key like UUID to implement equals and hashCode properly. Implementing those for a composite keys to play nicely with both collections and the db can be tricky.
As to your use case, a connection between users can be viewed as an entity of it's own and have a autogenerated surrogate PK. You can enforce the uniqueness of the business key attributes in the DB, see pt.3.
2. AFAIK, deciding between EmbeddedId and IdClass is mostly a matter of taste. I prefer
IdClass, since it avoids having to add navigation when querying id attributes:
... WHERE a.id.attribute = :att with EmbeddedId vs.
... WHERE a.attribute = :att vs. with IdClass
I do not find the argument you link 6 convincing. Composite keys tend to consist of the most characteristic attributes of the entity. To hide them away in a different class because they happen to be used as the DB key seems awkward to me.
3. Unique indexes look like a good way to guarantee uniqueness of a combination of attributes. You may want to read this answers, there is a small example.
If you are not yet working with JPA 2.1, you might want to use unique constraints, as explained here.
I understand the concept of aggregate root and I know that one aggregate root must reference another by identity ( http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf ) so what I don't get is how can I force Entity Framework to add a foreign key constraint between two aggregates?
Lets suppose I have a simplified domain:
public class AggregateOne{
[Key]
public Guid AggregateOneID{ get; private set;}
public Guid AggregateTwoFK{get; private set;}
/*Other Properties and methods*/
}
public class AggregateTwo{
[Key]
public Guid AggregateTwoID{get; private set;}
/*Other Properties and methods*/
}
With this domain design, Entity Framework doesn't know that there is a relationship between AggregateOne and AggregateTwo and consequently there is no foreign key at the generated database.
In DDD, EF doesn't exist. Domain relationships are not the same as database relationships. Don't try to mix EF with domain modeling, they don't work together. So in a nutshell, what you have there is not DDD, just plain old relational db masquerading as DDD. EF would be used by the Repositories and would care about persisting one Aggregate Root (AR).
Two ARs can work together, however you need to model the process according to the domain. EF is there to act as a db for the app, it's concerned with persistence issues and shouldn't care about the Domain. Persistence is all about storage and not about reflecting domain relationships (the EF entity is not the domain entity although they can have the same name and can look similar. The important detail is that both belong to different layers and handle different issues). The Domain repositories care only to persist the AR in a way that can be easily restored when it will change. If more AR need to be persisted together, embrace eventual consistency and learn how to use a service bus and sagas. It will greatly simplify your life (consider it a kind of implementation for the unit of work pattern).
For querying, the most clean and elegant way is to generate/update a read model suitable for the querying use cases and this is usually done after a domain event tells the 'world' that something changed in the Domain.
Doing DDD right is not straightforward and it's very easy to fall into the trap, believing that you apply DDD when in fact you're just CRUD ing away, using DDD terminology. Also IMO CQRS is a must with DDD if you like an easy life.
Understand the domain without rushing it and being superficial, identify the bounded contexts, model the domain concepts and their use cases (very important!!!), define repository interfaces as you need them, and implement the repositories only when there's nothing else left to do (the real repos, in the mean time you can use fake ones like in memory repos - they're very fast to implement and your app being decoupled means it shouldn't care about how persistence is implemented, right?). I know it sounds weird, but this how you know you have a maintainable DDD app.
The point of implementing the repositories last is to really decouple the app from the persistence details and also to have defined the expectations(repository methods) the app has from persistence. Once defined, you can write tests :D then implement the repositories. The bonus is that you get to focus only on repo implementation is isolation and when the all tests pass, you know everything works as it should.
Why should you have two complete different objects? Why not only expose your entities as domain objects through a domain interface?
In this case there's no issue with having your entities also act as domain objects with their implementation details neatly hidden behind the interface.
Another point a neat way to represent aggregate roots with EF is to make sure the foreign key column also makes up the primary key of the dependant entity. In your case that would mean AggregateOneId and AggregateTwoFk together would form the composite primary key of AggregateOne. This will ensure that EF doesn't need a repository for removing instances off AggregateOne as long as it's removed from AggregateTwo's collection it will be properly marked for deletion from the databases (if you don't have key like this you need to remove it from AggregateOne set because EF would throw an exception not understanding the intent of the developer that AggregateOne should be deleted.
Is it possible to use public key to apply digital signing and verifying the signatures through private key in PDF using iText?
Signing is done using private keys and verification is done using public key. The opposite scheme usually constitutes encryption (you encrypt data using public key and decrypt it using private key).