Complexity of templates and applications for the AEM6.5 publish

 

In this article, we can discuss how we can determine the number of servers (or CPU cores) you need for the AEM 6.5 publish environment for an applictaion having simple and complex templates.

Below is the formula to find out number of servers:

servers = n = (traffic * complexity / 1000 ) * activations

complexity = applicationComplexity + ((1-cacheRatio) * templateComplexity)

where:

traffic : The expected peak traffic per second. You can estimate this as the number of page hits per day, divided by 35'000.

Consider below Caching efficiency and traffic

Cache efficiency is crucial for the website speed. The following table shows how many pages per second an optimized AEM system can handle using a reverse proxy, such as the Dispatcher:

Cache ratio	Pages/s (peak)	Million pages/day (average)
100%	1000-2000	35-70
99%	910	32
95%	690	25
90%	520	18
60%	220	8
0%	100	3.5

applicationComplexity : 

Use 1 for a simple application, 2 for a complex application, or a value in-between:

• 1 - a fully anonymous, content orientated site
• 1.1 - a fully anonymous, content orientated site with client-side/Target personalization
• 1.5 - a content-orientated site with both anonymous and logged in sections, client-side/Target personalization
• 1.7 - for a content-orientated site with both anonymous and logged in sections, client-side/Target personalization and some user-generated content
• 2 - where the entire site requires login, with extensive use of user-generated content and various personalization techniques.

cacheRatio:

The percentage of pages that come out of the Dispatcher cache. 

Use 1 if all pages come from the cache, or 

0 if every page is computed by AEM.

templateComplexity:

Use a value from 1 through 10 to indicate the complexity of your templates. Higher numbers indicate more complex templates. 

Value 1 for sites with an average of 10 components per page, 

Value 5 for a page average of 40 components and 

value 10 for an average of over 100 components.

activations:

Number of average activations (replication of average sized pages and assets from the author to the publish tier) per hour divided by x, 

where x is the number of activations done on a system without performance side effects to other tasks processed by the system. 

Thanks for reading.

Happy coding!

Bundles not in AEM as a Cloud Service

 

There are 87 bundles not in AEM as a Cloud Service. Here is the list:

• com.adobe.aem.transaction-core – AEM Forms Transaction Core Bundle
• com.adobe.aemds.formsmanager.adobe-aemds-formsanddocuments-core – AEM Forms and Documents Core
• com.adobe.aemds.guide.aemds-guide-core – Adaptive Forms Core API
• com.adobe.aemds.guide.aemds-guide-core-impl – Adaptive Forms Core Implementation
• com.adobe.aemfd.ccm.multichannel-ccm-multi-channel-core – Multi Channel Core
• com.adobe.cq.commerce.cq-commerce-core – Adobe Communique 5 Commerce Core
• com.adobe.cq.commerce.cq-commerce-pim – Adobe Communique 5 Commerce Product Information Manager
• com.adobe.cq.commerce.cq-commerce-social – Adobe Communique 5 Commerce Social
• com.adobe.cq.cq-activitymap-integration – AEM 6 ActivityMap Integration Bundle
• com.adobe.cq.cq-pre-upgrade-backup – CQ Pre-upgrade Backup
• com.adobe.cq.cq-pre-upgrade-cleanup – CQ Pre-upgrade Cleanup
• com.adobe.cq.sample.we.retail.core – We.Retail – Core
• com.adobe.cq.screens.com.adobe.cq.screens – AEM Screens – Core
• com.adobe.cq.screens.com.adobe.cq.screens.apps.we_retail – Screens WeRetail
• com.adobe.cq.screens.com.adobe.cq.screens.dcc – AEM Screens – DCC
• com.adobe.cq.screens.com.adobe.cq.screens.mq.activemq – Adobe Screens Apache ActiveMQ Implementation
• com.adobe.cq.screens.com.adobe.cq.screens.mq.core – Adobe Screens JMS implementation
• com.adobe.cq.screens.com.adobe.cq.screens.sessions –
• com.adobe.cq.social.cq-social-activitystreams – AEM Communities ActivityStreams – Bundle
• com.adobe.cq.social.cq-social-as-provider – AEM Communities AdobeSocial Resource Provider – Bundle
• com.adobe.cq.social.cq-social-badging-api – AEM Communities Badging API – Bundle
• com.adobe.cq.social.cq-social-badging-basic-impl – AEM Communities Basic Badging – Bundle
• com.adobe.cq.social.cq-social-badging-impl – AEM Communities Badging – Bundle
• com.adobe.cq.social.cq-social-calendar-api – AEM Communities Calendar – API Bundle
• com.adobe.cq.social.cq-social-calendar-impl – AEM Communities Calendar – Impl Bundle
• com.adobe.cq.social.cq-social-commons – AEM Communities Commons – Bundle
• com.adobe.cq.social.cq-social-commons-oauth – AEM Communities Commons Oauth – Bundle
• com.adobe.cq.social.cq-social-console – AEM Communities Console – Bundle
• com.adobe.cq.social.cq-social-content-fragments-impl – AEM Communities Content Fragments Impl – Bundle
• com.adobe.cq.social.cq-social-enablement-api – AEM Communities Enablement Api – Bundle
• com.adobe.cq.social.cq-social-enablement-impl – AEM Communities Enablement Impl – Bundle
• com.adobe.cq.social.cq-social-filelibrary – AEM Communities File Library – Bundle
• com.adobe.cq.social.cq-social-forum – AEM Communities Forum – Bundle
• com.adobe.cq.social.cq-social-gamification-api – AEM Communities Gamification API – Bundle
• com.adobe.cq.social.cq-social-gamification-impl – AEM Communities Gamification Impl – Bundle
• com.adobe.cq.social.cq-social-graph-api – AEM Communities SocialGraph API – Bundle
• com.adobe.cq.social.cq-social-graph-impl – AEM Communities SocialGraph Impl – Bundle
• com.adobe.cq.social.cq-social-group – AEM Communities CommunityGroup – Bundle
• com.adobe.cq.social.cq-social-handlebars – AEM Communities Handlebars Scripting Engine – Bundle
• com.adobe.cq.social.cq-social-ideation-api – AEM Communities Ideation API – Bundle
• com.adobe.cq.social.cq-social-ideation-impl – AEM Communities Ideation – Bundle
• com.adobe.cq.social.cq-social-jcr-provider – Bundle –
• com.adobe.cq.social.cq-social-jcr-provider-common – AEM Communities JCR Resource Provider Common Code – Bundle
• com.adobe.cq.social.cq-social-journal – AEM Communities Journal – Bundle
• com.adobe.cq.social.cq-social-livefyre – AEM Livefyre – Bundle
• com.adobe.cq.social.cq-social-members-api – AEM Communities Members API – Bundle
• com.adobe.cq.social.cq-social-members-impl – AEM Communities Members Impl – Bundle
• com.adobe.cq.social.cq-social-messaging-api – AEM Communities Messaging – API Bundle
• com.adobe.cq.social.cq-social-messaging-impl – AEM Communities Messaging – Impl Bundle
• com.adobe.cq.social.cq-social-moderation – AEM Communities Moderation – Bundle
• com.adobe.cq.social.cq-social-moderation-spamdetector-core – AEM Communities Spam Detection Core – Bundle
• com.adobe.cq.social.cq-social-ms-provider – AEM Communities Mongo Storage Resource Provider – Bundle
• com.adobe.cq.social.cq-social-notifications-api – AEM Communities Notifications – API Bundle
• com.adobe.cq.social.cq-social-notifications-channels-web – AEM Communities Notifications – Web Channel
• com.adobe.cq.social.cq-social-notifications-impl – AEM Communities Notifications – IMPL Bundle
• com.adobe.cq.social.cq-social-qna – AEM Communities QnA – Bundle
• com.adobe.cq.social.cq-social-rdb-provider – AEM Communities Relational Social Resource Provider – Bundle
• com.adobe.cq.social.cq-social-reporting-management – AEM Communities Enablement Reporting Management- Bundle
• com.adobe.cq.social.cq-social-review – AEM Communities Review – Bundle
• com.adobe.cq.social.cq-social-scf-api – AEM Communities SCF – API Bundle
• com.adobe.cq.social.cq-social-scf-impl – AEM Communities SCF – Impl Bundle
• com.adobe.cq.social.cq-social-scoring-api – AEM Communities Scoring API – Bundle
• com.adobe.cq.social.cq-social-scoring-basic-impl – AEM Communities Scoring Basic – Bundle
• com.adobe.cq.social.cq-social-scoring-impl – AEM Communities Scoring – Bundle
• com.adobe.cq.social.cq-social-serviceusers-api – AEM Communities Service Users – Bundle
• com.adobe.cq.social.cq-social-serviceusers-impl – AEM Communities Service Users – Impl Bundle
• com.adobe.cq.social.cq-social-srp-api – AEM Communities SRP Base – API Bundle
• com.adobe.cq.social.cq-social-srp-impl – AEM Communities SRP – Impl Bundle
• com.adobe.cq.social.cq-social-sync – AEM Communities Sync – Bundle
• com.adobe.cq.social.cq-social-tally – AEM Communities Tally – Bundle
• com.adobe.cq.social.cq-social-translation – AEM Communities Translation – Bundle
• com.adobe.cq.social.cq-social-ugc-search-collections – AEM Communities UGC SearchCollections – Bundle
• com.adobe.cq.social.cq-social-ugcbase-api – AEM Communities UGC Base – API Bundle
• com.adobe.cq.social.cq-social-ugcbase-impl – AEM Communities UGC Base – Impl Bundle
• com.adobe.cq.social.cq-social-user-ugc-management – AEM Communities User Ugc Moderation – Bundle
• com.adobe.forms.common.adobe-xfaforms-common – Mobile Forms Common Bundle
• com.adobe.forms.foundation-forms-foundation-base – Forms Foundation Base Bundle
• com.adobe.forms.foundation-forms-foundation-cloud-config – Forms Foundation Cloud Configurations Bundle
• com.adobe.granite.apicontroller – Adobe Granite API Controller
• com.adobe.livecycle.formsportal-bundle – Adobe FormsPortal Services Bundle
• com.day.cq.cq-compat-codeupgrade – Day Communique 5 Code Upgrade service
• com.day.cq.cq-upgrades-executor – Adobe Communique 5 Upgrades Executor
• com.day.cq.dam.cq-dam-pim – Day Communique 5 DAM PIM Integration Implementation
• com.day.cq.dam.cq-dam-rating – Day Communique 5 Assets Rating
• com.day.cq.pre-upgrade-tasks – AEM Pre-Upgrade Maintenance Tasks
• forms-foundation-bundle – Forms Foundation Layer Bundle

For new bundles available in AEMaaCS .. refer here

New bundles in AEM Cloud

 

In this blog, we will discuss what New bundles in AEM as a Cloud Service(AEMaaCS) has been introduced.

AEM as a Cloud Service has some new bundles:

• com.adobe.bp.bp-cloudservice – Adobe Brand Portal Cloudservice configuration
• com.adobe.bp.bp-distribution – Adobe Brand Portal Distribution Implementation
• com.adobe.cq.cq-ref-update-processor-util – AEM – Reference Update Processor Utility bundle
• com.adobe.cq.dam.cq-dam-ui-models – AEM – DAM Sling Model Bundle
• com.adobe.cq.inbox.cq-inbox-api – AEM – Inbox API
• com.adobe.cq.remotedam.cq-remotedam-api – Adobe CQ Remote DAM API Bundle
• com.adobe.cq.ups-integration – Unified Profile Service IMS integration
• com.adobe.cq.ups-profile-lookup – Unified Profile Lookup routines
• com.adobe.granite.jobs.async.ui.commons – Adobe Granite Async Jobs
• com.adobe.granite.toggle.api – Adobe Granite Toggle API
• com.adobe.granite.toggle.impl – Adobe Granite Toggle Implementation
• com.adobe.granite.toggle.impl.static – Adobe Granite Toggle Implementation
• com.day.cq.dam.cq-dam-asset-sourcing – Day Communique 6 DAM Asset Sourcing Implementation
• com.day.cq.remote.content.renderer – Remote Content Renderer
• org.apache.felix.configadmin.plugin.interpolation – Apache Felix Configuration Admin Values Interpolation Plugin
• org.apache.felix.log – Apache Felix Log Service
• org.apache.felix.rootcause – Apache Felix – Root Cause Analysis
• org.apache.jackrabbit.oak-authorization-principalbased – Oak Principal-Based Authorization
• org.apache.sling.feature.apiregions – Apache Sling Feature API Regions Runtime
• rideau – Adobe Rideau (PDF API)

Difference between Bundle and Package in AEM

 

In this article, we will learn what exactly is the difference between Bundle and Package.

Bundle is a tightly coupled, dynamically loadable collection of classes, jars, and configuration files that explicitly declare their external dependencies (if any).

A Package is a zip file that contains the content in the form of a file-system serialization (called “vault” serialization) that displays the content from the repository as an easy-to-use-and-edit representation of files and folders. Packages can include content and project-related data.

Happy Coding!

How a JWT works?

 

In previous blog, we have learnt What is JWT, Anatomy and its authentication flow. Refer here to

In this blog, we will see how a JWT works via an example. We will create JWT for a specific JSON payload and validate its signature.

Step-1

 Create a JSON:

JSON payload example:

{

    "userId": "abcd123",

    "expiry": 1646635611301

}

Step-2

 Create a JWT signing key and decide the signing algorithm:

We can generate a signing key using any secure random source.

• Signing key: 
• NTNv7j0TuYARvmNMmWXo6fKvM4o6nv/aUi9ryX38ZH+L1bkrnD1ObOQ8JAUmHCBq7Iy7otZcyAagBLHVKvvYaIpmMuxmARQ97jUVG16Jkpkp1wXOPsrF9zwew6TpczyHkHgX5EuLg2MeBuiT/qJACs1J0apruOOJCg/gOtkjB4c=
• Signing algorithm: HMAC + SHA256, also known as HS256.

Step-3

Creating the “Header”:

This contains the information about which signing algorithm is used

{

    "typ": "JWT",

    "alg": "HS256"

}

Step-4

Create a Signature:

• First, we remove all the spaces from the payload JSON : {"userId":"abcd123","expiry":1646635611301}

• and then base64 encode it to give us eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ

• 
  
  
  

• You can try pasting this string in an https://www.base64decode.org/ to retrieve our JSON.

• Similarly, remove the spaces from the header JSON and base64 encode it

Header json: {"typ":"JWT","alg":"HS256"}

base64 encoded value: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

Now  concatenate <header>.<payload>

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ

Get the Signature:

run the Base64 + HMACSHA256 function on the above concatenated string

Base64URLSafe(

    HMACSHA256("eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ", "NTNv7j0TuYARvmNMmWXo6fKvM4o6nv/aUi9ryX38ZH+L1bkrnD1ObOQ8JAUmHCBq7Iy7otZcyAagBLHVKvvYaIpmMuxmARQ97jUVG16Jkpkp1wXOPsrF9zwew6TpczyHkHgX5EuLg2MeBuiT/qJACs1J0apruOOJCg/gOtkjB4c=")

)

Results in:

3Thp81rDFrKXr3WrY1MyMnNK8kKoZBX9lg-JwFznR-M

Java code:

Java HMAC SHA256

Dependent on Apache Commons Codec to encode in base64.

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import org.apache.commons.codec.binary.Base64;

public class ApiSecurityExample {
  public static void main(String[] args) {
    try {
     String secret = "secret";
     String message = "Message";

     Mac sha256_HMAC = Mac.getInstance("HmacSHA256");
     SecretKeySpec secret_key = new SecretKeySpec(secret.getBytes(), "HmacSHA256");
     sha256_HMAC.init(secret_key);

     String hash = Base64.encodeBase64String(sha256_HMAC.doFinal(message.getBytes()));
     System.out.println(hash);
    }
    catch (Exception e){
     System.out.println("Error");
    }
   }
}

Create JWT:


Append the generated signature like <header>.<body>.<signature>

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ.3Thp81rDFrKXr3WrY1MyMnNK8kKoZBX9lg-JwFznR-M

Verify JWT:

The authentication server will send the JWT back to the client’s frontend. 

The frontend will attach the JWT to network requests to the client’s api layer. 

At api layer, below steps are followed:

• Fetches the header part of the JWT (eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9).

base64 decoding on it to get the plain text JSON: {"typ":"JWT","alg":"HS256"}

• Verifies that the typ field’s value is JWT and the alg is HS256. It would reject the JWT if fails to verify.

Fetches signing secret key and runs the same Base64URLSafe(HMACSHA256(...))

If the incoming JWT’s body is different, this step will generate a different signature.

• Checks that the generated signature is the same as the signature from the incoming JWT. If it’s not, then the JWT is rejected.

base64 decode the body of the JWT (eyJ1c2VySWQiOiJhYmNkMTIzIiwiZXhwaXJ5IjoxNjQ2NjM1NjExMzAxfQ) to give us {"userId":"abcd123","expiry":1646635611301}.

If the current time (in milliseconds) is greater than the JSON’s expiry time (since the JWT is expired), JWT is rejected.

Accept the JWT if it approves all above steps.

Pros & Cons of JWT:

Advantages:

• Secure: JWTs are digitally signed using either a secret (HMAC) or a public/private key pair (RSA or ECDSA) which safeguards them from being modified by the client or an attacker.

Efficient / Stateless: It’s quick to verify a JWT since it doesn’t require a database lookup. 

• Stored only on the client: You generate JWTs on the server and send them to the client. The client then submits the JWT with every request. This saves database space.

Drawbacks:

Dependent on one secret key: The creation of a JWT depends on one secret key. If that key is compromised, the attacker can fabricate their own JWT which the API layer will accept.

Happy Coding!

What is JSON Web Tokens (JWT) and how to use?

 

Introduction:

Web authentication relied on cookies or sessions to authenticate users to web applications. These methods were good but had some drawbacks :

• Scalability, 
• Storage limitations, 
• Difficulty in integrating with third-party services

JWT solved these issues by providing a simple, secure, and flexible way to authenticate users in web applications. Lets discuss first what is JWT?

As per https://jwt.io/

"JSON Web Tokens(JWT) are an open, industry standard RFC 7519 method for representing claims securely between two parties."

It is self-contained method for securely transmitting information between parties as a JSON object. JWTs are a good way of securely transmitting information between parties because they can be signed, which means you can be certain that the senders are who they say they are.

Anatomy of a JWT:

A JSON Web Token is essentially a long encoded text string. This string is composed of three smaller parts, separated by a dot sign. These parts are:

• Header
• Payload/Body
• Signature

Anatomy of JWT

Header:

The header contains metadata about the token. It has 2 parts:

type- JWT  

algo-  cryptographic algorithm used to sign it.

{ "alg": "HS256", "typ": "JWT" }

Encoing format: encoded in Base64Url format.

Payload:

The payload contains the claims or information about the user. Claims are statements about an entity (typically, the user) and additional data.

{

  "sub": "1234567890",

  "name": "John Doe",

  "iat": 1516239022

}

Encoing format: encoded in Base64Url format.

Signature:

The signature is used to verify the integrity of the message and to ensure that it has not been tampered with. The signature is created by encoding the header and payload, concatenating them with a dot, and then signing the resulting string with a secret key using a cryptographic algorithm such as HMAC or RSA.

JWT Structure

JWT: <header>.<body>.<signature>

JWT claim Convention:

You may have noticed that in the JWT (that is issued by Google) example above, the JSON payload has non-obvious field names. They use sub, iat, aud and so on:

• iss: The issuer of the token (in this case Google)
• azp and aud: Client IDs issued by Google for your application. This way, Google knows which website is trying to use its sign in service, and the website knows that the JWT was issued specifically for them.
• sub: The end user’s Google user ID
• at_hash: The hash of the access token. The OAuth access token is different from the JWT in the sense that it’s an opaque token. The access token’s purpose is so that the client application can query Google to ask for more information about the signed in user.
• email: The end user’s email ID
• email_verified: Whether or not the user has verified their email.
• iat: The time (in milliseconds since epoch) the JWT was created
• exp: The time (in milliseconds since epoch) the JWT was created
• nonce: Can be used by the client application to prevent replay attacks.
• hd: The hosted G Suite domain of the user

JWT Authentication Flow:

JWT Authentication Flow

Why we need JWT?

• Secure: JWT is cryptographically signed, making it difficult to tamper with the token.
• Stateless: JWT is stateless, meaning the server does not need to keep track of the user’s session. This makes it more scalable and less storage-intensive.
• Third-party Integration: JWT can be easily integrated with third-party services like OAuth and OpenID Connect.
• Cross-Domain: JWT can be used for cross-domain authentication because it can be sent as a HTTP Authorization header.

How do they work (using an example) ? Refer here

Happy coding!