# idaas-access

Part of **IDAAS**

# IDaaS Access Control Troubleshooting Guide

## Problem Index

| Problem | Symptom | Severity | Solution Summary |
|--------|--------|----------|------------------|
| Identity Provider Name Mismatch | `The identity provider name does not match the one configured in RAM` | High | Ensure the Identity Provider Name in IDaaS matches the one in RAM console |
| Incorrect IdP Metadata Upload | SSO fails after metadata upload; user redirected to error page | High | Download correct metadata from IDaaS and re-upload to RAM console |
| Application User Name Mismatch | `User is not authorized to assume the specified role` | High | Set application user name in IDaaS to exactly match the RAM role name |
| Missing RAM Role Permissions | `AccessDenied: User is not authorized` during role assumption | Medium | Attach required policies to the RAM role used in SSO |
| SSO Login Timeout or Redirect Loop | Browser hangs or loops during SSO flow | Medium | Verify clock synchronization and certificate validity |

## Problem Details

### Problem 1: Identity Provider Name Mismatch

**Symptoms**
- Error message: `The identity provider name does not match the one configured in RAM`
- Behavior: SSO login fails immediately after redirect from IDaaS
- Context: Occurs when configuring Alibaba Cloud Role-based SSO between IDaaS and RAM

**Root Cause**
- The "Identity Provider Name" field in the IDaaS SSO configuration must exactly match the name of the identity provider created in the RAM console. A mismatch prevents RAM from recognizing the incoming SAML assertion.

**Solution**
1. Log in to the [Alibaba Cloud IDaaS console](https://yundun.console.aliyun.com/?p=idaas) and select your IDaaS instance.
2. Navigate to **Applications** > **Alibaba Cloud Role-based SSO** > **SSO Configuration**.
3. Note the value in the **Identity Provider Name** field.
4. Open the [RAM console](https://ram.console.aliyun.com).
5. In the left navigation pane, click **Identity Providers**.
6. Locate the configured identity provider and verify its name.
7. If names differ, update either the IDaaS **Identity Provider Name** or the RAM identity provider name to make them identical.

**Verification**
- After correction, initiate SSO login again.
- Expected behavior: User is successfully redirected to Alibaba Cloud console without error.

### Problem 2: Incorrect IdP Metadata Upload

**Symptoms**
- Behavior: SSO fails silently or returns a generic error after clicking the application icon
- Context: Occurs after initial setup or metadata regeneration in IDaaS

**Root Cause**
- The IdP metadata file uploaded to RAM contains outdated or incorrect SAML endpoints, certificates, or entity IDs. RAM uses this metadata to validate SAML responses from IDaaS.

**Solution**
1. In the IDaaS console, go to **Applications** > **Alibaba Cloud Role-based SSO** > **SSO Configuration**.
2. Click **Download Metadata File**.
3. In the RAM console, navigate to **Identity Providers**.
4. Find your identity provider and click **Manage**.
5. Click **Upload Metadata File** and select the newly downloaded file from IDaaS.
6. Save the changes.

**Verification**
- Test SSO by clicking the application icon in the IDaaS user portal.
- Check browser developer tools (Network tab) to confirm successful SAML POST to RAM endpoint.

### Problem 3: Application User Name Mismatch

**Symptoms**
- Error message: `User is not authorized to assume the specified role`
- Behavior: Login succeeds but role assumption fails; user cannot access target service
- Context: During role-based SSO, the application user name maps to a RAM role

**Root Cause**
- The **Application User Name** assigned to a user in IDaaS must exactly match the **Role Name** in RAM (including case). If they differ, RAM denies the `sts:AssumeRoleWithSAML` request.

**Solution**
1. In the IDaaS console, go to **Applications** > **Alibaba Cloud Role-based SSO** > **Application User**.
2. Select the affected user and note the **Application User Name**.
3. In the RAM console, go to **Roles** and locate the corresponding role.
4. Compare the **Role Name** with the **Application User Name**.
5. If they don’t match, either:
   - Update the **Application User Name** in IDaaS to match the RAM role name, or
   - Rename the RAM role (if permissible in your environment).

**Verification**
- Re-attempt SSO login.
- After successful login, check the assumed role in the Alibaba Cloud console header or via:
```bash
aliyun sts GetCallerIdentity
```
- Confirm the returned `Arn` contains the expected role name.

### Problem 4: Missing RAM Role Permissions

**Symptoms**
- Error message: `AccessDenied: User is not authorized`
- Behavior: User logs in successfully but cannot perform actions in target service
- Context: After successful SSO, user lacks permissions for intended operations

**Root Cause**
- The RAM role used in SSO lacks necessary policies attached to grant required permissions.

**Solution**
1. In the RAM console, go to **Roles**.
2. Find the role matching the application user name.
3. Click **Add Permissions**.
4. Attach appropriate managed or custom policies based on required access (e.g., `AliyunECSReadOnlyAccess` for read-only ECS access).
5. Ensure the trust policy allows `sts:AssumeRoleWithSAML` from the IDaaS identity provider.

**Verification**
- Log in via SSO and attempt the previously failing operation.
- Use the **Policy Simulation** tool in RAM to validate effective permissions.

### Problem 5: SSO Login Timeout or Redirect Loop

**Symptoms**
- Behavior: Browser redirects repeatedly between IDaaS and RAM, or session times out
- Context: Occurs during SAML flow; often intermittent

**Root Cause**
- Clock skew between IDaaS, RAM, and user device exceeds tolerance (typically 5 minutes), or SAML certificate has expired.

**Solution**
1. Ensure the system clock on the user’s device is synchronized (use NTP).
2. In the IDaaS console, verify the SAML signing certificate under **SSO Configuration** is valid and not expired.
3. If using custom certificates, renew and re-upload if near expiration.
4. Clear browser cookies for both `idaas.console.aliyun.com` and `signin.aliyun.com`.

**Verification**
- Attempt SSO login in an incognito/private browser window.
- Monitor network requests to confirm single, successful SAML exchange without repeated redirects.

## FAQ

**Q: How do I check if my SSO configuration is correct?**  
A: Verify three key elements: (1) Identity Provider Name matches in IDaaS and RAM, (2) IdP metadata in RAM is up-to-date, and (3) Application User Name in IDaaS exactly matches the RAM role name. Use the test login button in the IDaaS application dashboard to validate end-to-end flow.

**Q: What permissions are required to configure role-based SSO in IDaaS and RAM?**  
A: In IDaaS, you need `idaas:UpdateApplication` and `idaas:GetMetadata`. In RAM, you need `ram:CreateIdentityProvider`, `ram:UpdateIdentityProvider`, `ram:CreateRole`, and `ram:AttachPolicyToRole`. Typically granted via administrator roles or custom policies.

**Q: How do I enable debug logging for SSO issues?**  
A: While IDaaS doesn’t expose raw logs to users, you can inspect SAML requests/responses using browser developer tools (Network tab, filter for SAML POST). Also, check the **Audit Logs** in the IDaaS console under **Monitoring & Logging** for authentication events.

**Q: Can I use the same identity provider for multiple applications?**  
A: Yes, a single identity provider in RAM can be associated with multiple IDaaS applications, provided each application’s Identity Provider Name matches the RAM provider name and each uses a distinct RAM role mapped via Application User Name.

**Q: What should I do if the SSO metadata file download fails?**  
A: Ensure your IDaaS instance is active and the application is properly configured. If the **Download Metadata File** button is disabled, complete all required fields in the SSO configuration form first, especially **Identity Provider Name** and **Assertion Consumer Service (ACS) URL**.