Restricted Digital Library & Secure Virtual Access Environment

Secure Deployment of the Astan Quds Razavi Digital Library over VMware Horizon

Private Collections · Controlled Access · Virtual Desktop Delivery

Project positioning

This project was not a new digital-library platform built from scratch.

It was a restricted-access deployment of the existing Astan Quds Razavi Digital Library, created for content and functionality that were not intended to be exposed through the public website.

The same core digital-library concepts remained relevant:

bibliographic metadata,

search and discovery,

repository access,

record detail,

digital-resource viewing,

and institutional content.

The difference was the delivery and access model.

Instead of making all resources available through normal public web access, the restricted environment was delivered through VMware Horizon so that authorized users or authorized locations could access the internal version in a controlled virtual desktop environment.

The implementation and deployment work was carried out jointly by a two-person technical team, including me.

Classification

Project Type: Secure Digital Library Deployment / Virtual Desktop Access
Base Platform: Astan Quds Razavi Digital Library
Virtualization Platform: VMware Horizon
Access Model: Restricted / Controlled
Role: Joint implementation in a two-person technical team
Primary Domain: Secure Digital Access
Secondary Domains: Digital Library, Virtual Desktop Infrastructure, Restricted Content Delivery
Core Value: Reuse of an existing digital-library platform under a controlled-access deployment model
Portfolio Relevance: High
Suggested CV Relevance: Tier A/B — Secure Deployment, Enterprise Access, VDI

Website Card

Title:
Restricted Digital Library & Secure Virtual Access Environment

Subtitle:
Secure Deployment of the Astan Quds Razavi Digital Library over VMware Horizon

One-line Description:
A restricted-access deployment of the existing Astan Quds Razavi Digital Library delivered through VMware Horizon for content and functionality not intended for public web access.

Role:
Joint implementation by a two-person technical team.

Categories:

VMware Horizon
Virtual Desktop Infrastructure
Secure Access
Digital Library
Restricted Content
Enterprise Deployment
Institutional Platform

Concept Tags:
VMware Horizon · VDI · Restricted Access · Digital Library · Secure Deployment · Controlled Environment · Institutional Access

Executive Summary

The public Astan Quds Razavi Digital Library provided browser-based access to digital collections and library services.

However, not all parts of the platform were suitable for public exposure.

The organization therefore required a second delivery model for selected non-public content and functionality.

The solution was not to create an entirely separate software product.

Instead, the existing digital-library platform was reused and deployed inside a controlled virtual access environment using VMware Horizon.

Conceptually:

Astan Quds Razavi Digital Library
              ↓
      Same Core Platform
              ↓
       Access Classification
        ↙               ↘
Public Content      Restricted Content
     ↓                    ↓
Public Website       VMware Horizon
                          ↓
                Controlled Virtual Access

Core Design Principle

The project is best understood as:

Same application core, different trust boundary.

The software did not need to be reinvented.

The important engineering problem was:

How can an existing digital-library platform expose selected non-public resources without making them publicly reachable over the normal web?

Public vs Restricted Delivery

Public Deployment

Internet User
    ↓
Public Website
    ↓
Public Collections

Restricted Deployment

Authorized User / Location
          ↓
     VMware Horizon
          ↓
Controlled Virtual Desktop
          ↓
Restricted Digital Library
          ↓
Non-Public Resources

Why VMware Horizon

VMware Horizon was used as the delivery layer for the restricted environment.

This provided a controlled way to expose the application without requiring unrestricted public browser access to the underlying private environment.

The approach allowed the organization to keep:

the existing application model,
the familiar user interface,
the existing search and metadata workflows,

while changing how and where the system could be accessed.

Architectural Difference

The major difference between the public and restricted deployments was not the business logic.

It was the access architecture.

PUBLIC VERSION
Browser
  ↓
Public Web
  ↓
Public Data

RESTRICTED VERSION
Authorized Endpoint
  ↓
VMware Horizon
  ↓
Virtual Desktop / Controlled Session
  ↓
Restricted Application
  ↓
Private Data

Reuse of Existing Platform

The project reused the existing digital-library capabilities rather than duplicating them.

This is important from an architecture perspective.

Reusing the core platform avoids:

duplicate implementations,
duplicated metadata logic,
duplicated search behavior,
divergent user experience,
separate maintenance burden.

Shared Functional Core

The restricted deployment could reuse the same fundamental platform concepts:

Search
Metadata
Repositories
Record Detail
Digital Object Access
Viewer
Institutional Content

The restriction was introduced at the deployment and access layer.

Access Segmentation

The project introduced a practical separation between:

PUBLICLY ACCESSIBLE

and:

CONTROLLED / NON-PUBLIC

This is a common enterprise pattern.

The same organization may have information that belongs to different exposure levels.

Trust Boundary

The architecture created a stronger trust boundary around restricted content.

Instead of placing sensitive resources directly behind a normal public-facing web path, the restricted environment was accessed through a virtualized session.

Conceptually:

Internet
   ↓
Authentication / Access Control
   ↓
VMware Horizon
   ↓
Internal Application Environment

Virtual Desktop Delivery

VMware Horizon provided the user with a controlled virtual desktop/application session.

This changes the exposure model.

The user interacts with:

Session

rather than directly interacting with the restricted server environment from an arbitrary external browser.

Security Value

The important security benefit is not simply:

“VMware is secure.”

The real architectural advantage is that the restricted application remains inside a controlled infrastructure boundary.

This helps reduce direct exposure of:

application endpoints,
internal network topology,
private resources,
restricted data paths.

Controlled Endpoints / Locations

The restricted version was intended for special locations or users where non-public content could be made available under controlled conditions.

This means the access model could be aligned with:

designated terminals,
approved institutional locations,
authorized users,
controlled virtual sessions.

The exact historical authorization policy should only be described where documented.

Two-Person Technical Team

This deployment was implemented jointly by two people.

A precise portfolio description is:

Jointly implemented in a two-person technical team.

This is important because it preserves authorship accuracy.

My Contribution

My role belonged to the technical implementation and deployment of the restricted-access environment.

The project should be described as collaborative.

Avoid:

“I single-handedly built the VMware Horizon environment.”

Use:

“I jointly implemented the restricted digital-library environment using VMware Horizon as part of a two-person technical team.”

Deployment-Oriented Project

Unlike the public digital-library project, the main technical emphasis here is not metadata modeling.

It is:

DEPLOYMENT
+
ACCESS CONTROL
+
VIRTUAL DELIVERY
+
ENVIRONMENT SEGMENTATION

Relationship to the Public Digital Library

This project should be published independently, but clearly linked to the original Digital Library project.

The relationship is:

Project A
Astan Quds Razavi Digital Library
→ Public Digital Library Platform

Project B
Restricted Digital Library over VMware Horizon
→ Controlled Deployment of the Same Core Platform

Why This Should Be a Separate Portfolio Entry

Even though the application core was the same, the engineering problem was different.

The original project focused on:

metadata,
search,
discovery,
digital objects,
library services.

This project focused on:

restricted access,
deployment boundaries,
virtualized delivery,
infrastructure control.

These are distinct technical competencies.

Enterprise Deployment Pattern

This project represents a reusable enterprise architecture pattern:

ONE APPLICATION
      ↓
MULTIPLE DEPLOYMENT PROFILES
      ↓
Public
Internal
Restricted

Rather than creating separate codebases, one application can serve different trust zones.

Environment Separation

A mature design should separate environments such as:

Public Environment
Restricted Environment
Management Environment

Each can have different:

network rules,
authentication policies,
data exposure,
monitoring requirements.

Restricted Data Principle

The project followed a simple but important rule:

Content that should not be public should not depend only on hiding menu items.

Instead, access should be enforced structurally at the environment or authorization level.

VMware Horizon contributed to that controlled access boundary.

Defense-in-Depth Perspective

A strong modern interpretation of the design is:

Identity
  +
Authorized Device / Location
  +
Virtual Session
  +
Application Authorization
  +
Restricted Data

No single layer should be the only protection.

Authentication

The historical system already had application-level user concepts.

The VMware Horizon environment adds another possible control layer before the application itself.

Conceptually:

Horizon Authentication
        ↓
Virtual Session
        ↓
Application Authentication / Authorization

Exact historical authentication integrations should not be invented.

Session Isolation

Virtual desktop delivery helps isolate the restricted application inside a managed session.

A modern deployment may control:

clipboard,
file transfer,
printing,
USB redirection,
session timeout.

These are standard VDI capabilities but should be described as V2 or possible controls unless historical configuration evidence exists.

Data Leakage Considerations

For sensitive content, a VDI deployment can reduce—but not automatically eliminate—data leakage risks.

Potential policies include:

Disable Local Download
Disable Clipboard
Restrict Printing
Restrict Drive Mapping

Again, these are recommended/possible controls unless historically confirmed.

Network Architecture

A conceptual architecture:

Authorized User
      ↓
VMware Horizon Client / Portal
      ↓
Horizon Connection Layer
      ↓
Virtual Desktop / Application Session
      ↓
Restricted Digital Library
      ↓
Internal Data Services

Public Architecture Comparison

Public User
   ↓
Internet
   ↓
Web Server
   ↓
Digital Library

vs.

Authorized Restricted User
         ↓
      Horizon
         ↓
   Controlled Session
         ↓
 Restricted Digital Library

Operational Advantages

The VMware Horizon deployment offered several practical advantages:

centralized application delivery,
centralized maintenance,
controlled environment,
consistent client configuration,
separation from ordinary public access.

Centralized Maintenance

With virtual desktops/applications, the organization can manage the application centrally.

This avoids installing and maintaining a separate full environment on every authorized workstation.

Consistent Runtime

Users can receive a standardized environment.

This reduces problems caused by:

different browser versions,
local software differences,
missing dependencies,
inconsistent workstation configuration.

Legacy Application Compatibility

This is especially valuable for long-lived institutional software.

A restricted digital-library version may depend on:

older browser behavior,
legacy runtimes,
older frontend code,
specific local settings.

Virtualization can preserve a stable runtime even when endpoint environments change.

Long-Lived Institutional Software

The base Digital Library was already a multi-generation system.

VMware Horizon provided one strategy for continuing to deliver legacy/internal functionality without requiring every external endpoint to match the application’s historical requirements.

Application Modernization vs Virtualization

Two different strategies exist:

Rewrite / Modernize

Legacy Application
→ New Application

Virtualize / Contain

Legacy Application
→ Controlled Runtime
→ Virtual Delivery

This project used the second idea for the restricted-access requirement.

Why Not Duplicate the Application?

Creating a completely independent restricted system would introduce:

separate bug fixes,
metadata divergence,
duplicate feature development,
inconsistent search behavior,
higher maintenance cost.

Using the existing platform reduced duplication.

Data Segmentation

A robust modern architecture can implement restricted/public separation through:

separate databases,
separate schemas,
record-level visibility,
separate storage,
deployment-specific configuration.

The exact historical data-separation mechanism is not available from the current evidence.

Do not claim a specific model without documentation.

Feature Segmentation

Some functionality—not only data—may also be non-public.

Therefore deployment profiles can determine:

Feature Enabled?
Data Available?
User Authorized?

Feature Flags

A modern version could use explicit feature entitlements:

public.search
public.viewer
restricted.search
restricted.viewer
restricted.special_module

This is a V2 design recommendation.

Infrastructure as a Security Boundary

An important lesson from the project:

Application authorization and infrastructure access are complementary.

The system can enforce application permissions while VMware Horizon enforces where and how the application is delivered.

Logging

A modern restricted deployment should log:

Horizon login,
session start/end,
application login,
resource access,
privileged actions.

This creates a complete audit trail across infrastructure and application layers.

Monitoring

Useful operational metrics include:

concurrent sessions,
failed logins,
session duration,
application errors,
backend availability.

Availability

Because users depend on a remote virtual environment, the following components become operationally important:

Horizon Infrastructure
Network
Virtual Desktop Host
Application
Database
Storage

Failure in any layer can affect access.

Capacity Planning

A VDI solution must consider:

number of simultaneous users,
RAM per session,
CPU per session,
storage I/O,
session startup load.

This is a different engineering concern from normal public website scaling.

VDI Capacity Model

Conceptually:

Total Capacity
≈
Concurrent Sessions
×
Per-Session Resource Demand

Actual sizing requires measurement rather than fixed assumptions.

Security Hardening

A modern hardened deployment should consider:

MFA,
least privilege,
network segmentation,
session timeout,
hardened images,
restricted clipboard/download,
central patching.

These are modernization recommendations.

Disaster Recovery

A restricted institutional environment should also plan:

VM backups,
application backups,
database backups,
configuration backup,
restore testing.

High Availability

If the environment is mission-critical, Horizon components and application services can be made redundant.

This is a V2 infrastructure recommendation.

Update Strategy

The platform can be maintained centrally.

Example:

Update Application
      ↓
Test Restricted Environment
      ↓
Publish Updated Image / Session

This is safer than manually updating many endpoints.

Configuration Profiles

A modern deployment could use:

Public Profile
Restricted Profile

with environment variables controlling:

enabled modules,
API endpoints,
data sources,
authentication,
logging level.

Same Codebase, Different Deployment

This is the core architecture principle:

One Codebase
   ↓
Configuration
   ↓
Public Deployment
Restricted Deployment

This is more maintainable than long-term code forks.

Avoiding Fork Drift

If a separate copy of the source code is created for the restricted version, the two variants may drift.

Preferred approach:

Shared Core
+
Deployment Configuration
+
Feature Entitlements

Modern V2 Architecture

A contemporary equivalent could look like:

                Shared Application Core
                          │
              ┌───────────┴───────────┐
              ↓                       ↓
        Public Deployment       Restricted Deployment
              ↓                       ↓
        Reverse Proxy              VMware Horizon
              ↓                       ↓
        Public Users            Authorized Users

Identity Integration

A modern deployment may integrate Horizon and the application with enterprise identity such as:

Active Directory,
SSO,
MFA.

Only describe these as V2 possibilities unless historical integration is documented.

Zero-Trust Interpretation

A modern interpretation would avoid assuming that being on an internal network is enough.

Access decisions can depend on:

Identity
Device
Session
Authorization
Resource Sensitivity

User Experience

From the user’s perspective, the goal was to preserve familiarity.

The restricted version could still expose the same familiar library interface.

The major change was how the user reached it.

Training Cost

Reusing the same application reduced training needs.

Users did not need to learn an entirely separate library system just because the resources were restricted.

Support Model

Centralized deployment also simplifies support.

Support teams can reproduce issues in the same managed environment instead of dealing with many unknown endpoint configurations.

Historical vs Modern Boundary

Confirmed Historical Facts

The existing Astan Quds Razavi Digital Library was reused.
Some parts/content were considered unsuitable for public access.
A restricted-access deployment was created.
VMware Horizon was used to deliver that environment.
The work was implemented jointly by a two-person technical team.
The restricted deployment was intended for specific/authorized locations or users.

Modern Architecture Recommendations

explicit feature flags,
environment-specific configuration,
MFA,
SSO,
detailed VDI audit logging,
clipboard/download restrictions,
infrastructure-as-code,
zero-trust access policies.

These should not be presented as historical implementation unless separately evidenced.

What Not to Overclaim

Do not claim:

creation of VMware Horizon itself,
creation of the full Digital Library platform,
sole implementation of the deployment,
specific network security policies that are not documented,
specific Horizon features that were not actually configured.

My Role

A precise description:

I jointly implemented a restricted-access deployment of the existing Astan Quds Razavi Digital Library using VMware Horizon as part of a two-person technical team.

My contribution belonged to the deployment and controlled-access layer rather than ownership of the full digital-library product.

Engineering Highlights

Reused an existing institutional digital-library platform.
Created a separate restricted-access delivery model.
Used VMware Horizon for controlled virtual access.
Supported access to content/features not intended for the public website.
Avoided unnecessary duplication of the core application.
Preserved the existing search, metadata, and digital-resource workflows.
Worked jointly in a two-person technical team.
Introduced an infrastructure-level trust boundary around the restricted environment.

Career Evidence

This project demonstrates:

VMware Horizon
Virtual Desktop Infrastructure
Enterprise Deployment
Restricted Access Design
Application Reuse
Environment Segmentation
Legacy Application Delivery
Institutional Infrastructure
Collaborative Implementation
Security-Oriented Architecture

CV Relevance

Tier A/B — VDI & Secure Deployment

This project is useful because it shows experience beyond software development.

It demonstrates the ability to think about:

APPLICATION
+
INFRASTRUCTURE
+
ACCESS MODEL
+
DEPLOYMENT

as one system.

Interview Story

Situation

The organization already had a public digital-library platform, but some content and functionality were not suitable for unrestricted public web access.

Task

The organization needed a way to make those restricted resources available only in controlled environments without building and maintaining a completely separate digital-library product.

Action

As part of a two-person technical team, I helped implement a restricted deployment of the existing Digital Library using VMware Horizon.

The core application remained familiar to users, while access to the restricted version was delivered through a controlled virtual desktop environment.

Result

The organization could reuse the existing digital-library platform while maintaining a separate access boundary for non-public resources and functionality.

Suggested Website Full Description

Overview

The Restricted Digital Library & Secure Virtual Access Environment was created as a controlled deployment of the existing Astan Quds Razavi Digital Library.

Some resources and functions were not intended for public web access, so the platform was delivered through VMware Horizon for authorized environments.

Reuse Instead of Rewrite

The project reused the same digital-library core rather than creating a second independent product.

This preserved:

search behavior,
metadata handling,
record-detail workflows,
digital-resource access.

Restricted Access

The major difference was the trust boundary.

The public version was delivered normally through the web.

The restricted version was accessed through a VMware Horizon virtual environment.

Collaboration

The deployment was implemented jointly by a two-person technical team.

Short Website Card Copy

Restricted Digital Library over VMware Horizon

Jointly implemented a controlled-access deployment of the Astan Quds Razavi Digital Library for non-public resources, using VMware Horizon as the virtual delivery layer.

Alternative One-Liners

Infrastructure-oriented

Jointly implemented a VMware Horizon-based restricted deployment of an existing institutional digital-library platform.

Security-oriented

Separated public and restricted digital-library access by delivering non-public resources through a controlled VMware Horizon environment.

Architecture-oriented

Reused one digital-library application core across public and restricted deployment models rather than creating separate software products.

Legacy-delivery-oriented

Used VMware Horizon to provide controlled access to restricted functionality from a long-running institutional digital-library platform.

Suggested Website Slug

/projects/restricted-digital-library-vmware-horizon

Alternative:

/projects/secure-digital-library-vdi

Cover Direction

Title

Restricted Digital Library Access

Subtitle

VMware Horizon · Secure Virtual Delivery

Supporting Line

Public Core · Restricted Content · Controlled Access

Visual Direction

A premium square technical cover showing:

digital library interface,
virtual desktop window,
secure access gateway,
public vs restricted split,
lock / shield,
book/document icons,
VMware Horizon-style virtual session concept.

Primary visual story:

DIGITAL LIBRARY
      ↓
ACCESS CONTROL
      ↓
VMWARE HORIZON
      ↓
RESTRICTED ENVIRONMENT

Avoid making it look like:

a second independent library product,
cybersecurity software,
a VPN-only solution.

The key message is secure virtual delivery of an existing application.

Relationship to Portfolio Projects

This project should appear directly after:

Astan Quds Razavi Digital Library

The sequence becomes:

1. Public Digital Library
2. Restricted Digital Library over VMware Horizon

This makes the relationship immediately understandable.

Final Portfolio Statement

The engineering challenge was not to build another digital library.

It was to take an existing institutional platform and introduce a second, controlled delivery model for non-public resources.

The result combined:

EXISTING DIGITAL LIBRARY
+
RESTRICTED CONTENT
+
VMWARE HORIZON
+
CONTROLLED ACCESS
+
SHARED APPLICATION CORE

The project demonstrates an important enterprise principle:

Sometimes the correct solution is not a new application—it is a new trust boundary around the application that already exists.

Tags: Digital Library System Integration VMware