PRF

KDF

10.2 Enterprise Knowledge Graphs

The second type of these “Imperative Shell” services execute side-effects outside of the bounded context, such as sending an email, SMS, or mobile push notification to a user, or calling out to some other external service.

Unfortunately, numerous widely-used tagless-final interfaces (like Sync, Async, LiftIO, Concurrent, Effect, and ConcurrentEffect) encourage you to code to an implementation.

I have found that "publish subscribe" doesn't imply much more than indirect addressing of messages—if you compare any two messaging systems promising publish-subscribe, you find that they guarantee very different things, and most models are not useful in this domain.

The log will become something of a commoditized interface, with many algorithms and implementations competing to provide the best guarantees and optimal performance.

ACID

totally-ordered

It is an append-only, totally-ordered sequence of records ordered by time.

Independently on how the schema changes are handled, managing these changes is one of the most complex and error prone drawbacks associated with event sourcing. A strategy should be prepared upfront and considered on the system design.

Also your events will be based on a SomethingCreated or SomethingUpdated which has no business value at all. If the events are being designing like this then it is clear you’re not using DDD at all and you’re better of without event sourcing.

CQRS is not an architectural pattern and should not be applied to a whole system.

The theory says that in distributed systems everything is eventually consistent but the pragmatic view of the real world says that we need to be real careful on what we choose to make eventually consistent.

In this post, I'll walk you through everything you need to know about logs, including what is log and how to use logs for data integration, real time processing, and system building.

I think you don't hear much about using Kafka for event sourcing primarily because the event sourcing terminology doesn't seem to be very prevalent in the consumer web space where Kafka is most popular.

Another way to get consistency is to assure serialized writes, i.e using the single-writer principle, meaning we make sure all writes concerning a particular entity ID occur on a single thread.

One way to guarantee write consistency is by utilizing the event store’s optimistic concurrency control. A proper event store provides a way for the user to say “save this event only if the version of the entity is still x”.

If the business logic fails we return an error to the client but if it succeeds a new event is emitted. In that case we must be able to save the new event to our event store with a guarantee that no other event has been stored for this particular entity ID in the meantime, or we would risk breaking the consistency of our domain objects.

One alternative would be to have one topic per entity

Lightweight workflow engines. Examples

stateless processes

A resource owner may willingly delegate access to a resource by granting an access token to an attacker's malicious client.

The components of identity assurance detailed in these guidelines are as follows: IAL refers to the identity proofing process. AAL refers to the authentication process. FAL refers to the strength of an assertion in a federated environment, used to communicate authentication and attribute information (if applicable) to a relying party (RP).

8.3.2 Business Function A business function is a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization. Just like a business process, a business function also describes internal behavior performed by a business role. However, while a business process groups behavior based on a sequence or flow of activities that is needed to realize a product or service, a business function typically groups behavior based on required business resources, skills, competencies, knowledge, etc. There is a potential many-to-many relation between business processes and business functions. Complex processes in general involve activities that offer various functions. In this sense a business process forms a string of business functions. In general, a business function delivers added value from a business point of view. Organizational units or applications may coincide with business functions due to their specific grouping of business activities. A business function may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business function may access business objects. A business function may realize one or more business services and may be served by business, application, or technology services. A business role may be assigned to a business function. The name of a business function should clearly indicate a well-defined behavior. Examples are customer management, claims administration, member services, recycling, or payment processing. Figure 57: Business Function Notation

Authentication (from Greek: αὐθεντικός authentikos, "real, genuine", from αὐθέντης authentes, "author") is the act of proving an assertion, such as the identity of a computer system user.

If you are looking for stateless authorization at your APIs, that is a valid use case. Our recommendation however is to rely on opaque OAuth 2.0 Access Tokens and convert them to JSON Web Tokens at your API Gateway, for example by using ORY Oathkeeper.

In requests to the authorization server, a client MAY indicate the protected resource (a.k.a. resource server, application, API, etc.) to which it is requesting access by including the following parameter in the request.

protected resource (a.k.a. resource server, application, API, etc.)

But if we move completely into behavior land, then there’s definitely some kind of business action that brings the entity into existence. In our case this is place action. It’s a an integral verb of our domain and a part of the entity lifecycle, so we treat it accordingly — it belongs to the entity algebra.

Access - Performing an action

Authorization decision - The result of evaluating applicable policy, returned by the PDP to the238 PEP. A function that evaluates to “Permit”, “Deny”, “Indeterminate” or “NotApplicable", and 239 (optionally) a set of obligations

Once the End-User is authenticated, the Authorization Server MUST obtain an authorization decision before releasing information to the Relying Party. When permitted by the request parameters used, this MAY be done through an interactive dialogue with the End-User that makes it clear what is being consented to or by establishing consent via conditions for processing the request or other means (for example, via previous administrative consent).

session cookies

This enables an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for.

display OPTIONAL. ASCII string value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User. The defined values are:

The nonce parameter value needs to include per-session state and be unguessable to attackers.

ID Token

obtains End-User Consent/Authorization

when the ID Token has a single audience value and that audience is different than the authorized party

Client session

exp REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing.

It MAY also contain identifiers for other audiences.

The ID Token is a security token

    A security token is a set of information that facilitates the sharing
   of identity and security information in heterogeneous environments or
   across security domains.  Examples of security tokens include JSON
   Web Tokens (JWTs) [JWT] and SAML 2.0 Assertions
   [OASIS.saml-core-2.0-os].  Security tokens are typically signed to
   achieve integrity and sometimes also encrypted to achieve
   confidentiality.  Security tokens are also sometimes described as
   Assertions, such as in [RFC7521].

Claim Piece of information asserted about an Entity.

Authentication Context Class Reference

Authentication Request OAuth 2.0 Authorization Request

Authentication Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.

Authentication

authentication

Authorization Server

Security policy domain, also known as security domain or realm: A scope over which a common security policy is defined and enforced by the security administrator of the security service.

An ID Token typically comes with an expiration date. The RP MAY rely on it to expire the RP session. However, it is entirely possible that the End-User might have logged out of the OP before the expiration date. Therefore, it is highly desirable to be able to find out the login status of the End-User at the OP.

Session Continuous period of time during which an End-User accesses a Relying Party relying on the Authentication of the End-User performed by the OpenID Provider.

The id_token_hint parameter to a logout request can be used to determine which RP initiated the logout request. Logout requests without a valid id_token_hint value are a potential means of denial of service; therefore, OPs may want to require explicit user confirmation before acting upon them.

Opaque value used by the RP to maintain state between the logout request and the callback to the endpoint

If a cookie is used to maintain the OP browser state, the HttpOnly flag likely can't be set for this cookie because it needs to be accessed from JavaScript. Therefore, information that can be used for identifying the user should not be put into the cookie, as it could be read by unrelated JavaScript.

The authentication status of Clients being used by the End-User changes.

The set of users authenticated to the browser changes (login, logout, session add).

The OP browser state is typically going to be stored in a cookie or HTML5 local storage. It is origin bound to the Authorization Server. It captures meaningful events such as logins, logouts, change of user, change of authentication status for Clients being used by the End-User, etc. Thus, the OP SHOULD update the value of the browser state in response to such meaningful events.

Browser state

OP browser state

The generation of suitable Session State values is specified in Section 4.2 (OP iframe), and is based on a salted cryptographic hash of Client ID, origin URL, and OP browser state.

the End-User's login state at the OP

session management

In OpenID Connect, the session at the RP typically starts when the RP validates the End-User's ID Token.

The value of the "grant_type" is "urn:ietf:params:oauth:grant- type:jwt-bearer".