Using memberOf with AWS Client VPN and SAML: A Practical Guide to Group-Based Network Authorization

When AWS Client VPN is integrated with a SAML 2.0 identity provider, authentication answers one question:

Who is the user?

But many organizations need a second level of control:

Which networks should that user be allowed to access?

This is where the SAML memberOf attribute becomes useful.

AWS Client VPN can receive a user’s group membership in the SAML assertion and use that information in Client VPN authorization rules. This allows multiple user groups to authenticate through the same VPN application while receiving different levels of network access. AWS Documentation

---

1. What is memberOf?

memberOf is a SAML attribute that tells AWS Client VPN which identity-provider groups the authenticated user belongs to.

Conceptually, a SAML assertion might contain:

<Attribute Name="memberOf">
    <AttributeValue>
        group-123456
    </AttributeValue>
    <AttributeValue>
        group-789012
    </AttributeValue>
</Attribute>

This means:

User
 ├── belongs to Group A: group-123456
 └── belongs to Group B: group-789012

AWS Client VPN can inspect those group values and compare them with its authorization rules.

AWS specifically requires the attribute name to be:

memberOf

The name is case-sensitive when using SAML group-based authorization. AWS Documentation

---

2. Authentication vs Authorization

This distinction is the most important part of the design.

Authentication

Authentication determines whether the user can establish a VPN session.

For SAML authentication:

User
  ↓
AWS VPN Client
  ↓
SAML Identity Provider
  ↓
User signs in / MFA
  ↓
SAML assertion
  ↓
AWS Client VPN
  ↓
VPN session established

AWS Client VPN validates the SAML assertion and, if authentication succeeds, establishes the VPN connection. AWS Documentation

---

Authorization

Authorization determines:

What can the authenticated user reach through that VPN connection?

This happens through AWS Client VPN authorization rules.

For example:

Developers
    ↓
10.10.0.0/16

Database Admins
    ↓
10.20.10.0/24

Platform Admins
    ↓
10.0.0.0/8

AWS Client VPN authorization rules can associate a destination CIDR with a SAML group. Users who do not have a matching authorization rule do not get access to that network. The default behavior is deny unless access has been explicitly authorized. AWS Documentation

---

3. Why memberOf is useful

Consider an organization that has one VPN application assigned to three groups:

Corporate VPN Application

├── Developers
├── Database-Admins
└── Platform-Admins

All three groups may be permitted to authenticate to the same SAML application.

Without group-based authorization:

All authenticated users
        ↓
Same VPN access
        ↓
Potentially same networks

With memberOf:

                  SAML Application
                        │
        ┌───────────────┼───────────────┐
        │               │               │
   Developers      DB Admins      Platform Admins
        │               │               │
        └───────────────┼───────────────┘
                        │
                  memberOf values
                        │
                        ▼
                 AWS Client VPN
                        │
                 Authorization Rules
                 /          |          \
                /           |           \
      App Networks      DB Network     Admin Networks

You can therefore reuse one authentication system while applying different network permissions.

---

4. Example Scenario

Suppose an organization has these groups:

VPN-Developers
VPN-Database-Admins
VPN-Platform-Admins

The corresponding identity-provider group IDs might be:

VPN-Developers
Group ID:
11111111-aaaa-bbbb-cccc-111111111111

VPN-Database-Admins
Group ID:
22222222-aaaa-bbbb-cccc-222222222222

VPN-Platform-Admins
Group ID:
33333333-aaaa-bbbb-cccc-333333333333

A developer’s SAML assertion could contain:

<Attribute Name="memberOf">
    <AttributeValue>
        11111111-aaaa-bbbb-cccc-111111111111
    </AttributeValue>
</Attribute>

A platform engineer who belongs to two groups might receive:

<Attribute Name="memberOf">

    <AttributeValue>
        11111111-aaaa-bbbb-cccc-111111111111
    </AttributeValue>

    <AttributeValue>
        33333333-aaaa-bbbb-cccc-333333333333
    </AttributeValue>

</Attribute>

AWS Client VPN evaluates these group values against its authorization rules.

---

5. Example Authorization Rules

Consider this network:

Application VPC
10.10.0.0/16

Database subnet
10.10.50.0/24

Management subnet
10.10.100.0/24

Authorization could be designed as:

Group	Destination	Access
Developers	10.10.0.0/16	Application network
Database Admins	10.10.50.0/24	Database subnet
Platform Admins	10.10.100.0/24	Management subnet

For the Developers group:

Destination network:
10.10.0.0/16

Grant access to:
Users in a specific access group

Access Group ID:
11111111-aaaa-bbbb-cccc-111111111111

AWS requires the group ID/name entered in the authorization rule to match the group information returned in the SAML assertion. AWS Documentation

---

6. Example Access Flow

Suppose Alice is a Developer.

Alice
  ↓
Sign in through SAML IdP
  ↓
SAML assertion

memberOf =
11111111-aaaa-bbbb-cccc-111111111111
  ↓
AWS Client VPN
  ↓
Authorization rule lookup
  ↓
Developer group matches
  ↓
10.10.0.0/16 allowed

Now suppose Bob belongs only to the Database Admin group:

Bob
  ↓
VPN authentication succeeds
  ↓
memberOf =
22222222-aaaa-bbbb-cccc-222222222222
  ↓
No Developer rule matches
  ↓
10.10.0.0/16 access denied

But Bob may have another authorization rule allowing:

10.10.50.0/24

So the important point is:

A user may successfully connect to the VPN while still being unable to reach a particular network.

AWS demonstrates this behavior directly in its IAM Identity Center + Client VPN guidance: a user outside the authorized group can establish the VPN connection but cannot reach the protected network. Amazon Web Services, Inc.

---

7. IAM Identity Center Example

When AWS IAM Identity Center is used as the SAML identity provider, a typical attribute mapping is:

Application attribute	IAM Identity Center value	Format
Subject	${user:email}	emailAddress
memberOf	${user:groups}	unspecified

AWS documents this mapping specifically for AWS Client VPN. Identity Center passes group membership using group IDs, which are then referenced by Client VPN authorization rules. Amazon Web Services, Inc.

Conceptually:

IAM Identity Center

User
 ├── Developers
 └── Platform-Team
       ↓
${user:groups}
       ↓
memberOf
       ↓
SAML Assertion
       ↓
AWS Client VPN

---

8. Identity Provider vs Client VPN Authorization

A common source of confusion is the role of the IAM SAML Identity Provider.

The IAM SAML provider is not where group access is filtered.

Its job is primarily to establish trust between AWS and the SAML identity provider:

Identity Provider
       ↓
SAML metadata / certificates
       ↓
IAM SAML Provider
       ↓
AWS Client VPN

It does not provide a configuration such as:

Allow Group A
Deny Group B

Instead, the filtering happens here:

SAML IdP
   ↓
memberOf
   ↓
AWS Client VPN
   ↓
Authorization Rule
   ↓
Destination CIDR

So:

IAM SAML Provider
= Trust

memberOf
= Group identity information

Client VPN Authorization Rule
= Network access decision

---

9. Application Assignment vs Network Authorization

There are actually two useful levels of group control.

Level 1 — Application assignment

Controls:

Who can use the SAML VPN application?

Example:

VPN Application
   ↓
Assigned groups:
Developers
Platform-Team

A user not assigned to the application cannot normally use that application.

---

Level 2 — Client VPN authorization

Controls:

After authentication, what network can the user reach?

Example:

Developers
   ↓
10.10.0.0/16

Platform-Team
   ↓
10.20.0.0/16

These controls complement one another:

Identity Provider
      │
      │ Application assignment
      ▼
Can user authenticate?
      │
      ▼
AWS Client VPN
      │
      │ Authorization rules
      ▼
Which network can user access?

---

10. Multiple Groups Assigned to One SAML Application

A very useful scenario is:

VPN Application
├── Group A
└── Group B

Both groups can remain assigned to the application.

Suppose only Group A should access:

10.50.0.0/16

Configure:

Authorization Rule

Destination:
10.50.0.0/16

Access Group:
Group-A-ID

The result becomes:

Group A user
Authentication     ✅
VPN Connection     ✅
10.50.0.0/16       ✅


Group B user
Authentication     ✅
VPN Connection     ✅
10.50.0.0/16       ❌

This allows organizations to avoid creating a separate VPN or separate SAML application for every network-access group.

---

11. Multiple Authorization Rules

A single Client VPN endpoint can support multiple group-based authorization rules.

For example:

                         AWS Client VPN
                              │
          ┌───────────────────┼────────────────────┐
          │                   │                    │
          ▼                   ▼                    ▼
     Developers            DB Admins          Platform Admins

    10.10.0.0/16        10.20.10.0/24        10.30.0.0/16

Rules:

Developers
→ 10.10.0.0/16

Database-Admins
→ 10.20.10.0/24

Platform-Admins
→ 10.30.0.0/16

AWS Client VPN treats authorization rules as explicit grants. Traffic without a matching authorization rule is dropped. AWS Documentation

---

12. Users Belonging to Multiple Groups

A user may belong to several groups:

Alice
├── Developers
├── Platform
└── Database-ReadOnly

Her SAML assertion could contain multiple memberOf values:

<Attribute Name="memberOf">

    <AttributeValue>group-developers</AttributeValue>

    <AttributeValue>group-platform</AttributeValue>

    <AttributeValue>group-db-readonly</AttributeValue>

</Attribute>

Client VPN can then match Alice against every applicable authorization rule.

Her effective network access becomes the combination of the networks granted to those groups.

For example:

Developers
→ 10.10.0.0/16

Platform
→ 10.20.0.0/16

Database-ReadOnly
→ 10.30.50.0/24

Alice could therefore reach all three authorized destinations.

This is why group membership should be designed carefully: membership in any authorized group can grant the corresponding network access.

---

13. A Common Mistake: “Allow Access to All Users”

Suppose you configure:

Destination:
10.10.0.0/16

Allow access to all users:
True

and also configure:

Destination:
10.10.0.0/16

Access Group:
Developers

The group-specific rule does not turn the first rule into a deny rule.

AWS Client VPN authorization rules grant access; they do not create explicit deny rules. AWS Documentation

Therefore, if your objective is:

Only Developers should access the network

you should avoid an authorization rule that grants the same destination to all users.

Use:

Allow all users: FALSE

Access group:
Developers

---

14. Route vs Authorization Rule

Another important concept:

A route and an authorization rule solve different problems.

A route tells Client VPN:

Where should packets go?

An authorization rule tells Client VPN:

Which users are allowed to send packets there?

You generally need both.

User
 ↓
VPN
 ↓
Authorization Rule
"Is this user allowed?"
 ↓
Route
"Where should this packet go?"
 ↓
Destination

Example:

Route:
10.10.0.0/16 → VPC

Authorization:
Developers → 10.10.0.0/16

Having a route without authorization does not automatically grant the user access.

---

15. Security Groups Still Matter

memberOf does not replace VPC security controls.

The complete path may look like:

SAML authentication
       ↓
memberOf
       ↓
Client VPN authorization
       ↓
Client VPN route
       ↓
VPC routing
       ↓
Security Group
       ↓
Application / EKS / Database

For example, Client VPN might authorize:

Developers → 10.10.0.0/16

but a database security group may still permit only:

TCP 5432
from approved sources

Client VPN authorization should therefore be considered one layer in a defense-in-depth model, not a replacement for security groups.

---

16. Example: Private Kubernetes / EKS Access

A common use case is removing public access to a Kubernetes control plane.

Architecture:

Developer Laptop
      ↓
AWS VPN Client
      ↓
SAML Login
      ↓
Identity Provider
      ↓
memberOf
      ↓
AWS Client VPN
      ↓
Authorization Rule
      ↓
Private VPC
      ↓
Private Kubernetes API

Suppose:

Group:
Platform-Engineers

Destination:
10.40.0.0/16

Only users whose SAML assertion contains the Platform Engineers group value receive network authorization to the VPC.

They can then use local tooling such as:

kubectl get pods

without exposing the Kubernetes API publicly.

Authentication to Kubernetes itself remains a separate authorization layer:

VPN authorization
= Can reach Kubernetes API

Kubernetes/AWS IAM authorization
= What can the user do inside Kubernetes

This distinction is important.

VPN group access should not be confused with Kubernetes RBAC.

---

17. Example: Database Access

Another useful scenario:

VPN-Developers
VPN-DBA

Rules:

Developers
→ 10.10.0.0/16

DBA
→ 10.20.50.0/24

A DBA user:

memberOf = DBA-group-ID

may get access to:

10.20.50.0/24

while a developer does not.

Security groups can further restrict the database to:

TCP 5432

or:

TCP 3306

This creates layered controls:

Identity
→ Group
→ VPN network authorization
→ Security Group
→ Database authentication

---

18. Example: Environment Separation

One VPN endpoint could potentially serve several environments:

VPN-Development
VPN-Staging
VPN-Production

Authorization rules:

VPN-Development
→ 10.10.0.0/16

VPN-Staging
→ 10.20.0.0/16

VPN-Production
→ 10.30.0.0/16

A user belonging only to:

VPN-Staging

can authenticate to the common VPN but receive network authorization only for:

10.20.0.0/16

This is useful when organizations want one common authentication mechanism while maintaining environment-level segmentation.

---

19. Finding the Group ID

When IAM Identity Center is the IdP, AWS recommends using the Identity Center group ID, not merely assuming the friendly group name will be sent.

A group might look like:

Display name:
VPN-Developers

Group ID:
9067e4d8-1234-5678-abcd-123456789abc

The authorization rule should use:

9067e4d8-1234-5678-abcd-123456789abc

if that is the value returned by the SAML assertion. Amazon Web Services, Inc.

The key rule is:

Use exactly the group value returned in the SAML memberOf assertion.

---

20. How to Verify memberOf

With IAM Identity Center, AWS documents a handy troubleshooting method.

Sign in to the IAM Identity Center user portal and hold Shift while selecting the SAML VPN application. IAM Identity Center displays the generated SAML assertion, allowing you to inspect the memberOf values actually being sent. Amazon Web Services, Inc.

You should see something conceptually similar to:

<Attribute Name="memberOf">

    <AttributeValue>
        9067e4d8-1234-5678-abcd-123456789abc
    </AttributeValue>

</Attribute>

That exact value should correspond to:

Client VPN
→ Authorization Rules
→ Access Group ID

---

21. Troubleshooting Checklist

If authentication succeeds but network access fails, check:

1. Is memberOf spelled exactly correctly?
2. Is it mapped to the user’s groups in the IdP?
3. Does the SAML assertion actually contain the expected group ID?
4. Does the Client VPN authorization rule use that exact ID/value?
5. Is there an authorization rule for the required destination CIDR?
6. Does Client VPN have a route to that destination?
7. Do VPC route tables allow the path?
8. Do security groups/NACLs allow the required traffic?
9. Is DNS resolution working for private endpoints?
10. Does the user belong to the expected group?

AWS currently limits users to 200 groups for Client VPN group processing; groups beyond that limit are ignored. AWS Documentation

---

22. Recommended Design Pattern

A clean enterprise design looks like:

                         Identity Provider
                               │
                               │ SAML
                               │
                      memberOf = groups
                               │
                               ▼
                       AWS Client VPN
                               │
                 ┌─────────────┼─────────────┐
                 │             │             │
            Developers      DB Admins    Platform
                 │             │             │
                 ▼             ▼             ▼
              App VPC       DB subnet    Management

Use the IdP for:

• identity lifecycle
• MFA
• user/group membership
• SAML authentication

Use Client VPN for:

• destination-level network authorization
• group-to-CIDR mapping
• VPN connectivity

Use VPC/application controls for:

• ports
• protocols
• workload authorization
• application permissions

---

23. Key Takeaways

memberOf creates the bridge between identity groups and network authorization.

The overall model is:

User
 ↓
Identity Provider
 ↓
Authentication
 ↓
SAML assertion
 ↓
memberOf = Group IDs
 ↓
AWS Client VPN
 ↓
Authorization Rule
 ↓
Allowed Destination CIDR

The IAM SAML provider itself does not decide which group receives network access. It establishes the trust relationship used for federated authentication.

The Client VPN authorization rule is where the group value carried by memberOf is converted into actual network permissions.

This allows organizations to maintain one SAML application and one VPN endpoint while granting different network access to different groups, following least-privilege principles. AWS Documentation

You might also like

DevSecOps ManifestoWEBSITE HACKING & SEO SPAMINCIDENT RESPONSEWebsite Compromise → SEO Spam → Google Search Console Takeove