Remember the simplicity of managing your initial AWS infrastructure? A few EC2 instances and an RDS cluster were all manageable until your business and infrastructure grew. Now, you’re swamped with numerous AWS accounts, multiple VPCs, and a plethora of EC2 instances, ECS clusters, and RDS databases.

With the growth of your business and infrastructure, your engineering team expanded, and the convenience of everyone having access to everything has now become a ticking time bomb and a significant liability, deviating sharply from the principle of least privilege.

Sound familiar? You’re not alone! Many companies desire to reverse this trend, seeking more security, compartmentalization, control, and visibility. The ideal solution? One that integrates seamlessly with AWS, deploys in minutes, centers around Single Sign-On, and avoids complexities for engineering teams. That’s precisely what Border0 delivers!‍

Curious to see what Border0 for AWS looks like? Check out this quick 5 minute video Demo!

Border0 for AWS, a better together story

At Border0, our mission is to simplify access management for your AWS services, empowering AWS administrators and security teams to reclaim control and visibility. So today, we’re proud to share more details about our integration with AWS, providing organizations with a streamlined and secure access management journey with Single Sign-On for everything at the center.
‍
Border0 gives you back visibility and control over your AWS environments by offering granular access control and providing comprehensive audit trails, session logs, and session recordings, allowing you to see exactly who logged in when and even replay the session. It integrates flawlessly with many AWS services, including EC2, ECS, RDS, SSM, EC2 Instance Connect, CloudWatch, and Secrets Manager, to name a few. A modern-day PAM (privileged access management) solution for the cloud! Let’s dive in and explore!

Seamless SSO integration: Forget about static and shared credentials

Experience seamless Single Sign-On (SSO) integration for your AWS infrastructure and leave the complications of static and shared credentials behind. Border0 enables users to utilize their SSO credentials to access AWS EC2 instances, ECS containers, and RDS databases, eliminating the challenges associated with managing long-lived SSH keys and shared credentials.‍

Authorization and Fine-grained access control

A significant part of the challenge is the sprawl of access that engineers have. With Border0 policies, administrators can now establish dynamic access control rules to manage access to AWS resources based on specific SSO identities, conditions, and contexts, such as time of day, date, country, IP addresses, and even Pagerduty on-call status. For those seeking more customization, integration with existing policy systems or custom data sources is available, allowing the creation of even more tailored access control rules. This provides a centralized location to manage and enforce all access efficiently!‍

Consolidated visibility and Session recording

Collect all access events across your entire infrastructure centralized in one place, enabling real-time analysis and session replays. See who accessed what AWS resources, when, and from where. Using the session recording capability, you’ll be able to replay all sessions, allowing you to see exactly what database queries were executed by whom, or watch back a video recording of the SSH session! Use one of our integrations to notify your team in real-time by email or Slack of any new sessions, or export it all in real-time to AWS CloudWatch for further analysis.‍

Zero Trust access for your infrastructure

By moving to Border0 for access control, you also immediately move to a least privilege access model. You’re no longer providing users access to a network, like with a VPN, but only to the specific services you defined by policy. Moving away from a network-based perimeter security model limits attackers from pivoting and moving around laterally. Congratulations, you’re well on your way to implementing Zero Trust access for your infrastructure, even for resources in a private subnet!‍

Your engineers will love it!

Border0 not only gives you back control and visibility over who’s accessing your AWS services, but your engineers will love it too!

By using Border0, engineers can easily discover all the AWS resources they have access to. Accessing them can be done using their preferred tools (it turns out folks are pretty picky about what SSH or Database clients they use) or use our beautiful and easy-to-use web client, allowing users to access EC2 instances, ECS containers and even RDS databases using just their browser, any time, anywhere!

Finally, engineers no longer have to worry about jumping on and off various VPNs. And because we’ve eliminated shared secrets for the users, all they need is their SSO account.‍

Easy to install and get started

By now, you may be wondering how to get started. Good news! We’ve worked hard to ensure that adding Border0 to your AWS infrastructure is easy. To get started, you’ll need to install the Border0 connector into your existing AWS VPC(s). To help with this, we’ve made a cloud formation template available that can be launched using a web-based wizard or the following CLI command.

border0 connector install --aws

This will spin up an EC2 instance in the AWS VPC and Subnet of your choice. It will also make sure it has the correct IAM credentials, and three minutes later, you’re ready to go! The Border0 connector will register itself, after which it will appear alive in the Border0 portal.‍

‍Close integration with AWS

Border0’s close integration with AWS services and protocols ensures that turning AWS resources into Border0 Services is a low-effort task. Using the AWS discovery plugins, resources like EC2 instances, ECS clusters, and RDS databases will show up as discovered resources within seconds. You can then add them to Border0 with a single click.‍

The Border0 connector supports various upstream authentication methods, ensuring the right strategy is available depending on your use case. For example, in addition to static credentials like username and password, SSH keys, or certificates. We also support AWS-specific methods such as EC2 Instance Connect, AWS Systems Manager (SSM), and for databases, we support IAM-based authentication.‍

If you’re all in with AWS, then make sure also to enable the AWS CloudWatch integration and send Border0 session logs and audit events to CloudWatch. Additionally, you can use external secret vaults for upstream credentials, including AWS secrets manager or AWS SSM parameter store.‍

The Transformation: Before and After Border0

Before Border0, organizations struggled with high operational overhead, security challenges due to a lack of consolidated privilege management, over-provisioned access, use of shared secrets, and lack of visibility. After implementing Border0, organizations experienced a revolutionary shift and can now define granular access control rules that just make sense, are intuitive, builds on your SSO system, and take real-time context into account. The additional visibility and control is a significant upgrade, and due to the close integration with AWS, deploying Border0 into existing environments takes less than 5 minutes!

Best of all, your engineers will love it. With a single SSO login command, engineers can discover the AWS resources that are relevant to them. And log into EC2 instances, containers, Databases, and HTTP services using just their SSO credentials.‍

Wrap up

Border0 provides a modern-day Access Management solution for AWS. Built by and for security-conscious cloud-native organizations. Offering a harmonious blend of security, control, visibility, and simplicity. It addresses the challenges of growing infrastructures and provides a seamless, secure, and efficient environment for organizations to thrive in the cloud-native era.

But don’t just take my word for it; give it a try today and start your transformation journey with Border0. Sign up for our fully-featured free community edition or schedule a custom demo to explore a world where security and simplicity coexist and elevate your organization’s AWS access management with Border0.

The post Simplifying AWS Access with Border0 appeared first on ProdSens.live.

Have you ever experienced an error that keeps appearing under different circumstances and seems to be caused by random reasons? You can fix it once or twice but it comes back in a couple of days or in another environment or for another user. This was the error IDX21323 for me, it was so annoying that after a few cases I started saying “No, not you again!”

I worked with Federated Authentication in different versions of Sitecore and integrated it with multiple identity platforms such as Okta, Auth0 and Azure AD B2C. It is a good foundational layer that provides a lot of core functionality out-of-the-box, but there is still plenty of room for mistakes and learnings. In this article I want to share some of these learnings, specifically about the error IDX21323: RequireNonce is ‘[PII is hidden]’.

The main symptom of it is the fact that Sitecore does not authenticate the user correctly after successful redirect back from the identity provider login page. Instead of the configured redirectURL, it sends user to the /error page with the following message in the URL query string:

IDX21323: RequireNonce is ‘[PII is hidden]’. OpenIdConnectProtocolValidationContext.Nonce was null, OpenIdConnectProtocol.ValidatedIdToken.Payload.Nonce was not null. The nonce cannot be validated. If you don’t need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to ‘false’. Note if ‘nonce’ is found it will be evaluated.

The message itself is not very clear but we can see more details in the Owin.log file:

26672 08:37:29 WARN  Microsoft.Owin.Security.OpenIdConnect.OpenIdConnectAuthenticationMiddleware - The nonce cookie was not found.
26672 08:37:29 ERROR Microsoft.Owin.Security.OpenIdConnect.OpenIdConnectAuthenticationMiddleware - Exception occurred while processing message: 
Exception: Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectProtocolInvalidNonceException
Message: IDX21323: RequireNonce is '[PII is hidden]'. OpenIdConnectProtocolValidationContext.Nonce was null, OpenIdConnectProtocol.ValidatedIdToken.Payload.Nonce was not null. The nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'. Note if a 'nonce' is found it will be evaluated.
Source: Microsoft.IdentityModel.Protocols.OpenIdConnect
   at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectProtocolValidator.ValidateNonce(OpenIdConnectProtocolValidationContext validationContext) in C:agent2_work56ssrcMicrosoft.IdentityModel.Protocols.OpenIdConnectOpenIdConnectProtocolValidator.cs:line 639
   at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectProtocolValidator.ValidateAuthenticationResponse(OpenIdConnectProtocolValidationContext validationContext) in C:agent2_work56ssrcMicrosoft.IdentityModel.Protocols.OpenIdConnectOpenIdConnectProtocolValidator.cs:line 264
   at Microsoft.Owin.Security.OpenIdConnect.OpenIdConnectAuthenticationHandler.d__11.MoveNext()

Ultimately this error means that the Owin middleware was not able to read the nonce cookie. In fact, OpenIdConnectProtocolValidator can return many other error codes but I’ll focus just on one of them today. So why can this error appear?

Federated Authentication process

To answer this question, we need to understand how Sitecore Federated Authentication works and what it does behind the scenes.
Here is how the happy path should look like:

Step 1. Browser requests a page that contains a login link.
Step 2. Sitecore finds the IdentityProvider registered for the specified website name and generates login URL using the pipeline GetSignInUrlInfo.
Step 3. User clicks the login link and browser sends a POST request to the generated login URL.
The URL should start from /identity/externallogin?...
Step 4. The processor HandleLoginLink performs the following logic:

• ensures that the request method is POST
• includes RedirectUri parameter in the Authentication properties
• calls OWIN AuthenticationManager.Challenge() method passing the correct authentication type
  Then OWIN generates nonce, saves it in a cookie and redirects to the identity provider passing the nonce in the message.

Step 5. Browser redirects user to the Identity Provider sign in page.
Step 6. IDP authenticates the user and returns a JWT token.
Step 7. Browser redirects back to Sitecore application with JWT token.
Step 8. OWIN validates that nonce returned in the JWT token is valid and matches the original nonce cookie.
Sitecore IdentityProviderProcessor validates the token, authenticates the user and redirects to the specified RedirectUri.

If something goes wrong at any of these steps, the error IDX21323 can appear. There are some common reasons that can cause it:

• Sitecore pipeline GetSignInUrlInfo was not used for generating the sign in URL.
• Original domain of the website and the configured redirect URL domain are different, therefore Sitecore does not have access to the nonce cookie after redirect back from the identity provider.
• Cookies or session was cleared between the sign in URL generation and redirect back from the external provider.
• Nonce cookie is returned by the server but the browser blocks it.
• ASP.NET Session ID cookie is not created.

For example, the last time I saw this error it was intermittent and happened only on one machine and we could not reproduce it anywhere else. It turned out that the problem was caused by the disabled xDB.Enabled and xDB.Tracking.Enabled settings. If a request to the login page was made in a new incognito browser window, there was no ASP.NET Session ID cookie created before the redirect was made to the identity provider, therefore Sitecore could not validate that the response from the identity provider was made from the same user session.

Troubleshooting steps

If you faced this error, the following steps can help to troubleshoot it:

1. Look at requests on the browser Network tab.
   It can be an IIS redirect that breaks the POST request and the problem is not even in the nonce cookie!
2. Check that the cookies are generated and saved correctly – both ASP.NET Session ID and nonce cookie.
3. If the website redirects back to the /error page, check the error message in query string.
4. Review Sitecore log and Owin.log for any relevant error messages.

Bonus tip:
If you have just started integration and don’t have any components that display the logged in user details yet, create a simple test rendering that will output all information required for debugging.

The post Sitecore Federated Authentication and that annoying error IDX21323: RequireNonce is ‘[PII is hidden]’ appeared first on ProdSens.live.

Easiest and free way to add login service to any project.

Step 1A: Signup at logify.id

After sign in, you will get this screen, click on Continue as individual

Step 1B: Register your organization

Click on the Work tab at the top right corner.

Click Create New Organization from left navigation bar

Note: if you are not an organization, you can register with your project name.

Fill the organization details. Lets take an example of indeed where users go to search for jobs. Here indeed’s designated employee will register the organization.

Step 1C: Register your domain

Click on organization name (i.e. indeed) on top left corner.

Click on Domain on left navigation bar

Click on Add new Domain which is at top right side.

Fill the form and create a Domain.

After domain creation, View Domain button will appear at top right corner. Click on that button to get the domain key.

Step 2: Setup React Project
Create new folder with name react-logify-basic

Open react-logify-basic in visual studio code

Run git clone https://github.com/logify-access/react-logify-basic.git . in terminal to clone the repository. Github Repo

Install all dependencies with npm i

Create .env file

Paste REACT_APP_LOGIFY_DOMAINKEY = YOUR_DOMAIN_KEY

Step 3: Run the Project
Start your project with npm start

If I click on the login button, I can see login screen

After login, I can see my details.

The post How to implement login in React appeared first on ProdSens.live.