search

IT-REX-Platform / wiki

MIT License
1 stars 0 forks source link

12 Authorization Concept #19

Closed myluki2000 closed 1 year ago

myluki2000 commented 1 year ago

This PR includes the wiki pages describing our Authorization Concept as discussed by me, @PaulBredl and @BlueWaves2

PaulBredl commented 1 year ago

Stupid question I just had. Why doesn't the media/content whatever just stores which course it belongs to? That would mean the media service only has to ask the keycloak. I think we reasons for not making it this may, but I don't remember them.

As far as I know, we don't allow that content is moved to another course, and even that would not be too complicated.

myluki2000 commented 1 year ago

Why doesn't the media/content whatever just stores which course it belongs to?

We said that we want to prevent data duplication if possible, thus we don't want to store the relationship both on the course and on the media end. Also, because it wouldn't even be a direct relationship, because there also sits "Chapter" and "MediaContent" between Course and Media

PaulBredl commented 1 year ago

But the duplication is not a problem because we don't allow moving content from one service to another and even if we did it would still be less complicated than having this unnecessary call chain from a content service.

myluki2000 commented 1 year ago

Remember that we're talking about the media records here, stored on the MediaService, not MediaContent! And media records totally can be linked by multiple courses and linkings might be changed. Media records are not course-specific, they're just files linked to by some course's chapter's contents

myluki2000 commented 1 year ago

Also this is just one example. Even if we'd store the course id in the content and break the chain early (we'd still have to do at least a part of the chain for the reasons described earlier), then this would end up with the system having a special implementation just for this case. Because there will be parts of the system where storing the course id directly in the item would be ugly.

This would result in us having to have specific implementations depending on where we store the course id for each and every item in the system. I'd rather have this be standardized and not having to worry about in which cases we can or can't store the course id somewhere else and also having to worry about consistency, even if it means a little overhead.

myluki2000 commented 1 year ago

Also, as discussed, if the overhead of the permission queries becomes an issue, we can just perform caching. This is "the best of both worlds". We don't have to worry about data consistency (cache invalidation means eventual consistency) and at the same time can have a unified system of querying permissions for every item in the graphql hierarchy.

PaulBredl commented 1 year ago

@myluki2000 I'm gonna be honest, I personally dislike this approach but you guys put the brain into it and I understand your reasoning.

myluki2000 commented 1 year ago

I mean we could also ask customer Niklas if he is happy with this design or if he rather wants something else. Shouldn't take too long, we could do it this evening.

Keyshal-211 commented 1 year ago

Fine for me with your Conversation.