{"id":3150,"date":"2026-09-29T09:24:44","date_gmt":"2026-09-29T09:24:44","guid":{"rendered":"https:\/\/devsecopsschool.com\/blog\/?p=3150"},"modified":"2026-09-29T09:24:45","modified_gmt":"2026-09-29T09:24:45","slug":"using-memberof-with-aws-client-vpn-and-saml-a-practical-guide","status":"publish","type":"post","link":"http:\/\/devsecopsschool.com\/blog\/using-memberof-with-aws-client-vpn-and-saml-a-practical-guide\/","title":{"rendered":"Using memberOf with AWS Client VPN and SAML: A Practical Guide"},"content":{"rendered":"\n

Using memberOf<\/code> with AWS Client VPN and SAML: A Practical Guide to Group-Based Network Authorization<\/p>\n\n\n\n

When AWS Client VPN is integrated with a SAML 2.0 identity provider, authentication answers one question:<\/p>\n\n\n\n

\n

Who is the user?<\/strong><\/p>\n<\/blockquote>\n\n\n\n

But many organizations need a second level of control:<\/p>\n\n\n\n

\n

Which networks should that user be allowed to access?<\/strong><\/p>\n<\/blockquote>\n\n\n\n

This is where the SAML memberOf<\/code><\/strong> attribute becomes useful.<\/p>\n\n\n\n

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

\n\n\n\n

1. What is memberOf<\/code>?<\/h2>\n\n\n\n

memberOf<\/code> is a SAML attribute that tells AWS Client VPN which identity-provider groups the authenticated user belongs to.<\/p>\n\n\n\n

Conceptually, a SAML assertion might contain:<\/p>\n\n\n\n

<Attribute Name=\"memberOf\">\n    <AttributeValue>\n        group-123456\n    <\/AttributeValue>\n    <AttributeValue>\n        group-789012\n    <\/AttributeValue>\n<\/Attribute><\/code><\/pre>\n\n\n\n
This means:<\/p>\n\n\n\n
User\n \u251c\u2500\u2500 belongs to Group A: group-123456\n \u2514\u2500\u2500 belongs to Group B: group-789012<\/code><\/pre>\n\n\n\n
AWS Client VPN can inspect those group values and compare them with its authorization rules.<\/p>\n\n\n\n
AWS specifically requires the attribute name to be:<\/p>\n\n\n\n
memberOf<\/code><\/pre>\n\n\n\n
The name is case-sensitive<\/strong> when using SAML group-based authorization. AWS Documentation<\/a><\/p>\n\n\n\n
\n\n\n\n
2. Authentication vs Authorization<\/h1>\n\n\n\n
This distinction is the most important part of the design.<\/p>\n\n\n\n
Authentication<\/h2>\n\n\n\n
Authentication determines whether the user can establish a VPN session.<\/p>\n\n\n\n
For SAML authentication:<\/p>\n\n\n\n
User\n  \u2193\nAWS VPN Client\n  \u2193\nSAML Identity Provider\n  \u2193\nUser signs in \/ MFA\n  \u2193\nSAML assertion\n  \u2193\nAWS Client VPN\n  \u2193\nVPN session established<\/code><\/pre>\n\n\n\n
AWS Client VPN validates the SAML assertion and, if authentication succeeds, establishes the VPN connection. AWS Documentation<\/a><\/p>\n\n\n\n
\n\n\n\n
Authorization<\/h2>\n\n\n\n
Authorization determines:<\/p>\n\n\n\n
\n
What can the authenticated user reach through that VPN connection?<\/strong><\/p>\n<\/blockquote>\n\n\n\n
This happens through AWS Client VPN authorization rules<\/strong>.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Developers\n    \u2193\n10.10.0.0\/16\n\nDatabase Admins\n    \u2193\n10.20.10.0\/24\n\nPlatform Admins\n    \u2193\n10.0.0.0\/8<\/code><\/pre>\n\n\n\n
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<\/a><\/p>\n\n\n\n
\n\n\n\n
3. Why memberOf<\/code> is useful<\/h1>\n\n\n\n
Consider an organization that has one VPN application assigned to three groups:<\/p>\n\n\n\n
Corporate VPN Application\n\n\u251c\u2500\u2500 Developers\n\u251c\u2500\u2500 Database-Admins\n\u2514\u2500\u2500 Platform-Admins<\/code><\/pre>\n\n\n\n
All three groups may be permitted to authenticate to the same SAML application.<\/p>\n\n\n\n
Without group-based authorization:<\/p>\n\n\n\n
All authenticated users\n        \u2193\nSame VPN access\n        \u2193\nPotentially same networks<\/code><\/pre>\n\n\n\n
With memberOf<\/code>:<\/p>\n\n\n\n
                  SAML Application\n                        \u2502\n        \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n        \u2502               \u2502               \u2502\n   Developers      DB Admins      Platform Admins\n        \u2502               \u2502               \u2502\n        \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                        \u2502\n                  memberOf values\n                        \u2502\n                        \u25bc\n                 AWS Client VPN\n                        \u2502\n                 Authorization Rules\n                 \/          |          \\\n                \/           |           \\\n      App Networks      DB Network     Admin Networks<\/code><\/pre>\n\n\n\n
You can therefore reuse one authentication system while applying different network permissions.<\/p>\n\n\n\n
\n\n\n\n
4. Example Scenario<\/h1>\n\n\n\n
Suppose an organization has these groups:<\/p>\n\n\n\n
VPN-Developers\nVPN-Database-Admins\nVPN-Platform-Admins<\/code><\/pre>\n\n\n\n
The corresponding identity-provider group IDs might be:<\/p>\n\n\n\n
VPN-Developers\nGroup ID:\n11111111-aaaa-bbbb-cccc-111111111111\n\nVPN-Database-Admins\nGroup ID:\n22222222-aaaa-bbbb-cccc-222222222222\n\nVPN-Platform-Admins\nGroup ID:\n33333333-aaaa-bbbb-cccc-333333333333<\/code><\/pre>\n\n\n\n
A developer’s SAML assertion could contain:<\/p>\n\n\n\n
<Attribute Name=\"memberOf\">\n    <AttributeValue>\n        11111111-aaaa-bbbb-cccc-111111111111\n    <\/AttributeValue>\n<\/Attribute><\/code><\/pre>\n\n\n\n
A platform engineer who belongs to two groups might receive:<\/p>\n\n\n\n
<Attribute Name=\"memberOf\">\n\n    <AttributeValue>\n        11111111-aaaa-bbbb-cccc-111111111111\n    <\/AttributeValue>\n\n    <AttributeValue>\n        33333333-aaaa-bbbb-cccc-333333333333\n    <\/AttributeValue>\n\n<\/Attribute><\/code><\/pre>\n\n\n\n
AWS Client VPN evaluates these group values against its authorization rules.<\/p>\n\n\n\n
\n\n\n\n
5. Example Authorization Rules<\/h1>\n\n\n\n
Consider this network:<\/p>\n\n\n\n
Application VPC\n10.10.0.0\/16\n\nDatabase subnet\n10.10.50.0\/24\n\nManagement subnet\n10.10.100.0\/24<\/code><\/pre>\n\n\n\n
Authorization could be designed as:<\/p>\n\n\n\n
Group<\/th>Destination<\/th>Access<\/th><\/tr><\/thead>
Developers<\/td>10.10.0.0\/16<\/code><\/td>Application network<\/td><\/tr>
Database Admins<\/td>10.10.50.0\/24<\/code><\/td>Database subnet<\/td><\/tr>
Platform Admins<\/td>10.10.100.0\/24<\/code><\/td>Management subnet<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For the Developers group:<\/p>\n\n\n\n
Destination network:\n10.10.0.0\/16\n\nGrant access to:\nUsers in a specific access group\n\nAccess Group ID:\n11111111-aaaa-bbbb-cccc-111111111111<\/code><\/pre>\n\n\n\n
AWS requires the group ID\/name entered in the authorization rule to match the group information returned in the SAML assertion. AWS Documentation<\/a><\/p>\n\n\n\n
\n\n\n\n
6. Example Access Flow<\/h1>\n\n\n\n
Suppose Alice is a Developer.<\/p>\n\n\n\n
Alice\n  \u2193\nSign in through SAML IdP\n  \u2193\nSAML assertion\n\nmemberOf =\n11111111-aaaa-bbbb-cccc-111111111111\n  \u2193\nAWS Client VPN\n  \u2193\nAuthorization rule lookup\n  \u2193\nDeveloper group matches\n  \u2193\n10.10.0.0\/16 allowed<\/code><\/pre>\n\n\n\n
Now suppose Bob belongs only to the Database Admin group:<\/p>\n\n\n\n
Bob\n  \u2193\nVPN authentication succeeds\n  \u2193\nmemberOf =\n22222222-aaaa-bbbb-cccc-222222222222\n  \u2193\nNo Developer rule matches\n  \u2193\n10.10.0.0\/16 access denied<\/code><\/pre>\n\n\n\n
But Bob may have another authorization rule allowing:<\/p>\n\n\n\n
10.10.50.0\/24<\/code><\/pre>\n\n\n\n
So the important point is:<\/p>\n\n\n\n
\n
A user may successfully connect to the VPN while still being unable to reach a particular network.<\/p>\n<\/blockquote>\n\n\n\n
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.<\/a><\/p>\n\n\n\n
\n\n\n\n
7. IAM Identity Center Example<\/h1>\n\n\n\n
When AWS IAM Identity Center is used as the SAML identity provider, a typical attribute mapping is:<\/p>\n\n\n\n
Application attribute<\/th>IAM Identity Center value<\/th>Format<\/th><\/tr><\/thead>
Subject<\/code><\/td>${user:email}<\/code><\/td>emailAddress<\/code><\/td><\/tr>
memberOf<\/code><\/td>${user:groups}<\/code><\/td>unspecified<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
AWS documents this mapping specifically for AWS Client VPN. Identity Center passes group membership using group IDs<\/strong>, which are then referenced by Client VPN authorization rules. Amazon Web Services, Inc.<\/a><\/p>\n\n\n\n
Conceptually:<\/p>\n\n\n\n
IAM Identity Center\n\nUser\n \u251c\u2500\u2500 Developers\n \u2514\u2500\u2500 Platform-Team\n       \u2193\n${user:groups}\n       \u2193\nmemberOf\n       \u2193\nSAML Assertion\n       \u2193\nAWS Client VPN<\/code><\/pre>\n\n\n\n
\n\n\n\n
8. Identity Provider vs Client VPN Authorization<\/h1>\n\n\n\n
A common source of confusion is the role of the IAM SAML Identity Provider.<\/p>\n\n\n\n
The IAM SAML provider is not where group access is filtered<\/strong>.<\/p>\n\n\n\n
Its job is primarily to establish trust between AWS and the SAML identity provider:<\/p>\n\n\n\n
Identity Provider\n       \u2193\nSAML metadata \/ certificates\n       \u2193\nIAM SAML Provider\n       \u2193\nAWS Client VPN<\/code><\/pre>\n\n\n\n
It does not provide a configuration such as:<\/p>\n\n\n\n
Allow Group A\nDeny Group B<\/code><\/pre>\n\n\n\n
Instead, the filtering happens here:<\/p>\n\n\n\n
SAML IdP\n   \u2193\nmemberOf\n   \u2193\nAWS Client VPN\n   \u2193\nAuthorization Rule\n   \u2193\nDestination CIDR<\/code><\/pre>\n\n\n\n
So:<\/p>\n\n\n\n
IAM SAML Provider\n= Trust\n\nmemberOf\n= Group identity information\n\nClient VPN Authorization Rule\n= Network access decision<\/code><\/pre>\n\n\n\n
\n\n\n\n
9. Application Assignment vs Network Authorization<\/h1>\n\n\n\n
There are actually two useful levels of group control.<\/p>\n\n\n\n
Level 1 \u2014 Application assignment<\/h2>\n\n\n\n
Controls:<\/p>\n\n\n\n
\n
Who can use the SAML VPN application?<\/p>\n<\/blockquote>\n\n\n\n
Example:<\/p>\n\n\n\n
VPN Application\n   \u2193\nAssigned groups:\nDevelopers\nPlatform-Team<\/code><\/pre>\n\n\n\n
A user not assigned to the application cannot normally use that application.<\/p>\n\n\n\n
\n\n\n\n
Level 2 \u2014 Client VPN authorization<\/h2>\n\n\n\n
Controls:<\/p>\n\n\n\n
\n
After authentication, what network can the user reach?<\/p>\n<\/blockquote>\n\n\n\n
Example:<\/p>\n\n\n\n
Developers\n   \u2193\n10.10.0.0\/16\n\nPlatform-Team\n   \u2193\n10.20.0.0\/16<\/code><\/pre>\n\n\n\n
These controls complement one another:<\/p>\n\n\n\n
Identity Provider\n      \u2502\n      \u2502 Application assignment\n      \u25bc\nCan user authenticate?\n      \u2502\n      \u25bc\nAWS Client VPN\n      \u2502\n      \u2502 Authorization rules\n      \u25bc\nWhich network can user access?<\/code><\/pre>\n\n\n\n
\n\n\n\n
10. Multiple Groups Assigned to One SAML Application<\/h1>\n\n\n\n
A very useful scenario is:<\/p>\n\n\n\n
VPN Application\n\u251c\u2500\u2500 Group A\n\u2514\u2500\u2500 Group B<\/code><\/pre>\n\n\n\n
Both groups can remain assigned to the application.<\/p>\n\n\n\n
Suppose only Group A should access:<\/p>\n\n\n\n
10.50.0.0\/16<\/code><\/pre>\n\n\n\n
Configure:<\/p>\n\n\n\n
Authorization Rule\n\nDestination:\n10.50.0.0\/16\n\nAccess Group:\nGroup-A-ID<\/code><\/pre>\n\n\n\n
The result becomes:<\/p>\n\n\n\n
Group A user\nAuthentication     \u2705\nVPN Connection     \u2705\n10.50.0.0\/16       \u2705\n\n\nGroup B user\nAuthentication     \u2705\nVPN Connection     \u2705\n10.50.0.0\/16       \u274c<\/code><\/pre>\n\n\n\n
This allows organizations to avoid creating a separate VPN or separate SAML application for every network-access group.<\/p>\n\n\n\n
\n\n\n\n
11. Multiple Authorization Rules<\/h1>\n\n\n\n
A single Client VPN endpoint can support multiple group-based authorization rules.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
                         AWS Client VPN\n                              \u2502\n          \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n          \u2502                   \u2502                    \u2502\n          \u25bc                   \u25bc                    \u25bc\n     Developers            DB Admins          Platform Admins\n\n    10.10.0.0\/16        10.20.10.0\/24        10.30.0.0\/16<\/code><\/pre>\n\n\n\n
Rules:<\/p>\n\n\n\n
Developers\n\u2192 10.10.0.0\/16\n\nDatabase-Admins\n\u2192 10.20.10.0\/24\n\nPlatform-Admins\n\u2192 10.30.0.0\/16<\/code><\/pre>\n\n\n\n
AWS Client VPN treats authorization rules as explicit grants. Traffic without a matching authorization rule is dropped. AWS Documentation<\/a><\/p>\n\n\n\n
\n\n\n\n
12. Users Belonging to Multiple Groups<\/h1>\n\n\n\n
A user may belong to several groups:<\/p>\n\n\n\n
Alice\n\u251c\u2500\u2500 Developers\n\u251c\u2500\u2500 Platform\n\u2514\u2500\u2500 Database-ReadOnly<\/code><\/pre>\n\n\n\n
Her SAML assertion could contain multiple memberOf<\/code> values:<\/p>\n\n\n\n
<Attribute Name=\"memberOf\">\n\n    <AttributeValue>group-developers<\/AttributeValue>\n\n    <AttributeValue>group-platform<\/AttributeValue>\n\n    <AttributeValue>group-db-readonly<\/AttributeValue>\n\n<\/Attribute><\/code><\/pre>\n\n\n\n
Client VPN can then match Alice against every applicable authorization rule.<\/p>\n\n\n\n
Her effective network access becomes the combination of the networks granted to those groups.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Developers\n\u2192 10.10.0.0\/16\n\nPlatform\n\u2192 10.20.0.0\/16\n\nDatabase-ReadOnly\n\u2192 10.30.50.0\/24<\/code><\/pre>\n\n\n\n
Alice could therefore reach all three authorized destinations.<\/p>\n\n\n\n
This is why group membership should be designed carefully: membership in any authorized group can grant the corresponding network access<\/strong>.<\/p>\n\n\n\n
\n\n\n\n
13. A Common Mistake: “Allow Access to All Users”<\/h1>\n\n\n\n
Suppose you configure:<\/p>\n\n\n\n
Destination:\n10.10.0.0\/16\n\nAllow access to all users:\nTrue<\/code><\/pre>\n\n\n\n
and also configure:<\/p>\n\n\n\n
Destination:\n10.10.0.0\/16\n\nAccess Group:\nDevelopers<\/code><\/pre>\n\n\n\n
The group-specific rule does not turn the first rule into a deny rule.<\/p>\n\n\n\n
AWS Client VPN authorization rules grant access; they do not create explicit deny rules<\/strong>. AWS Documentation<\/a><\/p>\n\n\n\n
Therefore, if your objective is:<\/p>\n\n\n\n
\n
Only Developers should access the network<\/p>\n<\/blockquote>\n\n\n\n
you should avoid an authorization rule that grants the same destination to all users.<\/p>\n\n\n\n
Use:<\/p>\n\n\n\n
Allow all users: FALSE\n\nAccess group:\nDevelopers<\/code><\/pre>\n\n\n\n
\n\n\n\n
14. Route vs Authorization Rule<\/h1>\n\n\n\n
Another important concept:<\/p>\n\n\n\n
A route<\/strong> and an authorization rule<\/strong> solve different problems.<\/p>\n\n\n\n
A route tells Client VPN:<\/p>\n\n\n\n
\n
Where should packets go?<\/p>\n<\/blockquote>\n\n\n\n
An authorization rule tells Client VPN:<\/p>\n\n\n\n
\n
Which users are allowed to send packets there?<\/p>\n<\/blockquote>\n\n\n\n
You generally need both.<\/p>\n\n\n\n
User\n \u2193\nVPN\n \u2193\nAuthorization Rule\n\"Is this user allowed?\"\n \u2193\nRoute\n\"Where should this packet go?\"\n \u2193\nDestination<\/code><\/pre>\n\n\n\n
Example:<\/p>\n\n\n\n
Route:\n10.10.0.0\/16 \u2192 VPC\n\nAuthorization:\nDevelopers \u2192 10.10.0.0\/16<\/code><\/pre>\n\n\n\n
Having a route without authorization does not automatically grant the user access.<\/p>\n\n\n\n
\n\n\n\n
15. Security Groups Still Matter<\/h1>\n\n\n\n
memberOf<\/code> does not replace VPC security controls.<\/p>\n\n\n\n
The complete path may look like:<\/p>\n\n\n\n
SAML authentication\n       \u2193\nmemberOf\n       \u2193\nClient VPN authorization\n       \u2193\nClient VPN route\n       \u2193\nVPC routing\n       \u2193\nSecurity Group\n       \u2193\nApplication \/ EKS \/ Database<\/code><\/pre>\n\n\n\n
For example, Client VPN might authorize:<\/p>\n\n\n\n
Developers \u2192 10.10.0.0\/16<\/code><\/pre>\n\n\n\n
but a database security group may still permit only:<\/p>\n\n\n\n
TCP 5432\nfrom approved sources<\/code><\/pre>\n\n\n\n
Client VPN authorization should therefore be considered one layer in a defense-in-depth model<\/strong>, not a replacement for security groups.<\/p>\n\n\n\n
\n\n\n\n
16. Example: Private Kubernetes \/ EKS Access<\/h1>\n\n\n\n
A common use case is removing public access to a Kubernetes control plane.<\/p>\n\n\n\n
Architecture:<\/p>\n\n\n\n
Developer Laptop\n      \u2193\nAWS VPN Client\n      \u2193\nSAML Login\n      \u2193\nIdentity Provider\n      \u2193\nmemberOf\n      \u2193\nAWS Client VPN\n      \u2193\nAuthorization Rule\n      \u2193\nPrivate VPC\n      \u2193\nPrivate Kubernetes API<\/code><\/pre>\n\n\n\n
Suppose:<\/p>\n\n\n\n
Group:\nPlatform-Engineers\n\nDestination:\n10.40.0.0\/16<\/code><\/pre>\n\n\n\n
Only users whose SAML assertion contains the Platform Engineers group value receive network authorization to the VPC.<\/p>\n\n\n\n
They can then use local tooling such as:<\/p>\n\n\n\n
kubectl get pods<\/code><\/pre>\n\n\n\n
without exposing the Kubernetes API publicly.<\/p>\n\n\n\n
Authentication to Kubernetes itself remains a separate authorization layer<\/strong>:<\/p>\n\n\n\n
VPN authorization\n= Can reach Kubernetes API\n\nKubernetes\/AWS IAM authorization\n= What can the user do inside Kubernetes<\/code><\/pre>\n\n\n\n
This distinction is important.<\/p>\n\n\n\n
VPN group access should not be confused with Kubernetes RBAC.<\/p>\n\n\n\n
\n\n\n\n
17. Example: Database Access<\/h1>\n\n\n\n
Another useful scenario:<\/p>\n\n\n\n
VPN-Developers\nVPN-DBA<\/code><\/pre>\n\n\n\n
Rules:<\/p>\n\n\n\n
Developers\n\u2192 10.10.0.0\/16\n\nDBA\n\u2192 10.20.50.0\/24<\/code><\/pre>\n\n\n\n
A DBA user:<\/p>\n\n\n\n
memberOf = DBA-group-ID<\/code><\/pre>\n\n\n\n
may get access to:<\/p>\n\n\n\n
10.20.50.0\/24<\/code><\/pre>\n\n\n\n
while a developer does not.<\/p>\n\n\n\n
Security groups can further restrict the database to:<\/p>\n\n\n\n
TCP 5432<\/code><\/pre>\n\n\n\n
or:<\/p>\n\n\n\n
TCP 3306<\/code><\/pre>\n\n\n\n
This creates layered controls:<\/p>\n\n\n\n
Identity\n\u2192 Group\n\u2192 VPN network authorization\n\u2192 Security Group\n\u2192 Database authentication<\/code><\/pre>\n\n\n\n
\n\n\n\n
18. Example: Environment Separation<\/h1>\n\n\n\n
One VPN endpoint could potentially serve several environments:<\/p>\n\n\n\n
VPN-Development\nVPN-Staging\nVPN-Production<\/code><\/pre>\n\n\n\n
Authorization rules:<\/p>\n\n\n\n
VPN-Development\n\u2192 10.10.0.0\/16\n\nVPN-Staging\n\u2192 10.20.0.0\/16\n\nVPN-Production\n\u2192 10.30.0.0\/16<\/code><\/pre>\n\n\n\n
A user belonging only to:<\/p>\n\n\n\n
VPN-Staging<\/code><\/pre>\n\n\n\n
can authenticate to the common VPN but receive network authorization only for:<\/p>\n\n\n\n
10.20.0.0\/16<\/code><\/pre>\n\n\n\n
This is useful when organizations want one common authentication mechanism<\/strong> while maintaining environment-level segmentation.<\/p>\n\n\n\n
\n\n\n\n
19. Finding the Group ID<\/h1>\n\n\n\n
When IAM Identity Center is the IdP, AWS recommends using the Identity Center group ID<\/strong>, not merely assuming the friendly group name will be sent.<\/p>\n\n\n\n
A group might look like:<\/p>\n\n\n\n
Display name:\nVPN-Developers\n\nGroup ID:\n9067e4d8-1234-5678-abcd-123456789abc<\/code><\/pre>\n\n\n\n
The authorization rule should use:<\/p>\n\n\n\n
9067e4d8-1234-5678-abcd-123456789abc<\/code><\/pre>\n\n\n\n
if that is the value returned by the SAML assertion. Amazon Web Services, Inc.<\/a><\/p>\n\n\n\n
The key rule is:<\/p>\n\n\n\n
\n
Use exactly the group value returned in the SAML memberOf<\/code> assertion.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n
20. How to Verify memberOf<\/code><\/h1>\n\n\n\n
With IAM Identity Center, AWS documents a handy troubleshooting method.<\/p>\n\n\n\n
Sign in to the IAM Identity Center user portal and hold Shift while selecting the SAML VPN application<\/strong>. IAM Identity Center displays the generated SAML assertion, allowing you to inspect the memberOf<\/code> values actually being sent. Amazon Web Services, Inc.<\/a><\/p>\n\n\n\n
You should see something conceptually similar to:<\/p>\n\n\n\n
<Attribute Name=\"memberOf\">\n\n    <AttributeValue>\n        9067e4d8-1234-5678-abcd-123456789abc\n    <\/AttributeValue>\n\n<\/Attribute><\/code><\/pre>\n\n\n\n
That exact value should correspond to:<\/p>\n\n\n\n
Client VPN\n\u2192 Authorization Rules\n\u2192 Access Group ID<\/code><\/pre>\n\n\n\n
\n\n\n\n
21. Troubleshooting Checklist<\/h1>\n\n\n\n
If authentication succeeds but network access fails, check:<\/p>\n\n\n\n
    \n
  1. Is memberOf<\/code> spelled exactly correctly?<\/li>\n\n\n\n
  2. Is it mapped to the user’s groups in the IdP?<\/li>\n\n\n\n
  3. Does the SAML assertion actually contain the expected group ID?<\/li>\n\n\n\n
  4. Does the Client VPN authorization rule use that exact ID\/value?<\/li>\n\n\n\n
  5. Is there an authorization rule for the required destination CIDR?<\/li>\n\n\n\n
  6. Does Client VPN have a route to that destination?<\/li>\n\n\n\n
  7. Do VPC route tables allow the path?<\/li>\n\n\n\n
  8. Do security groups\/NACLs allow the required traffic?<\/li>\n\n\n\n
  9. Is DNS resolution working for private endpoints?<\/li>\n\n\n\n
  10. Does the user belong to the expected group?<\/li>\n<\/ol>\n\n\n\n
    AWS currently limits users to 200 groups for Client VPN group processing<\/strong>; groups beyond that limit are ignored. AWS Documentation<\/a><\/p>\n\n\n\n
    \n\n\n\n
    22. Recommended Design Pattern<\/h1>\n\n\n\n
    A clean enterprise design looks like:<\/p>\n\n\n\n
                             Identity Provider\n                               \u2502\n                               \u2502 SAML\n                               \u2502\n                      memberOf = groups\n                               \u2502\n                               \u25bc\n                       AWS Client VPN\n                               \u2502\n                 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                 \u2502             \u2502             \u2502\n            Developers      DB Admins    Platform\n                 \u2502             \u2502             \u2502\n                 \u25bc             \u25bc             \u25bc\n              App VPC       DB subnet    Management<\/code><\/pre>\n\n\n\n
    Use the IdP for:<\/p>\n\n\n\n