Canvas LMS IDP Auto Token Refresh

Automatically refresh Canvas LMS API tokens via institutional CAS/SAML IDP login using RSA-encrypted credentials and manage token lifecycle.

Security Scan

The skill appears to implement the claimed Canvas IDP token-refresh flow, but there are clear metadata/instruction mismatches and sensitive debug artifacts that raise caution before installing or running with real credentials.

Purpose & Capability

The code and SKILL.md implement exactly what the name/description claim (replay institutional CAS/SAML login, RSA-encrypt password, create Canvas API token, optionally delete old tokens). Requested capabilities (username/password, session cookies, Canvas token CRUD) align with the stated purpose. However the registry metadata lists no required environment variables while the scripts and SKILL.md require ELEARNING_USERNAME and ELEARNING_PASSWORD — a clear metadata/instruction inconsistency.

Instruction Scope

Runtime instructions require creating a .env with username/password and running the packaged Python scripts. The scripts produce debug artifacts (entry_response.html, auth_execute.json, cookies.txt, create_token.json, etc.) which may contain session cookies, CSRF tokens, encrypted payloads and potentially raw token values. SKILL.md cautions about sanitizing debug files, but the default tooling writes these to disk and the script prints NEW_TOKEN to stdout — both are sensitive outputs that could be captured or leaked if run in shared environments.

Install Mechanism

There is no platform install spec, but SKILL.md instructs users to create a Python venv and pip install packages from PyPI (requests, beautifulsoup4, pycryptodome, python-dotenv). These are common libraries and the risk is moderate (network installs from PyPI). No downloads from unknown servers or obfuscated install steps are present.

Credentials

The script legitimately needs ELEARNING_USERNAME and ELEARNING_PASSWORD (and optional URL overrides) to perform IDP login. That is proportionate to the purpose. However the skill's registry metadata declares no required environment variables or primary credential, which is inconsistent and could mislead users into thinking no sensitive secrets are needed. The code also loads dotenv and will read environment variables at runtime.

Persistence & Privilege

The skill is not always-enabled and does not request elevated platform privileges. It does not modify other skills or system-wide agent settings. It operates on provided credentials and the target Canvas/IDP endpoints only.

What to consider before installing

This package implements the claimed Canvas IDP login and token lifecycle operations, but treat it as sensitive software before running: - Do not run with your primary/high-privilege account. Create a restricted test account if possible. - The script requires ELEARNING_USERNAME and ELEARNING_PASSWORD (set in .env or env vars). The registry metadata failing to declare these is an inconsistency — verify the skill source and author before supplying secrets. - Avoid running with --debug on shared systems; debug_output/ will contain cookies, CSRF tokens, encrypted payloads and other sensitive artifacts. If you must debug, inspect and securely delete artifacts afterward. - The script prints NEW_TOKEN to stdout; ensure whatever captures stdout (agent logs, CI logs) is secure and that you do not accidentally commit tokens or debug files to source control. - Review the bundled Python files yourself (they are included) and confirm endpoints (ELEARNING_ENTRY_URL, ELEARNING_IDP_BASE_URL, token API URL) are correct for your institution. Consider removing or sanitizing debug-dump calls before using in production. - Prefer native OAuth/OIDC flows or long-lived API tokens if available; this kind of credential replay is brittle (CAPTCHA, MFA) and carries risk. If you need higher assurance: ask the publisher for a homepage/source repo, confirm provenance, or run the code in an isolated environment (ephemeral VM/container) and test with a non-sensitive account. If the metadata cannot be corrected (declaring required env vars), treat that as a red flag and proceed cautiously.

Automate Canvas API token refresh by replaying institutional IDP login (CAS/SAML) with RSA-encrypted credentials.

How It Works

Entry URL → CAS/IDP (lck + authChainCode) → RSA encrypt password → authExecute
  → loginToken (JWT) → authnEngine → SSO ticket → Canvas session → create API token
  → (optional) delete old tokens by purpose → output NEW_TOKEN=xxx

The script handles the full IDP chain: cookie juggling, JavaScript-redirect handoff, CSRF extraction, and Canvas API token CRUD.

Quick Start

1. Install Dependencies

cd scripts/
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt

Dependencies: requests, beautifulsoup4, pycryptodome, python-dotenv.

2. Configure Credentials

Copy .env.example to .env and fill in:

cp scripts/.env.example scripts/.env

Required fields:

• ELEARNING_USERNAME — student/staff ID
• ELEARNING_PASSWORD — password

Optional (defaults to Fudan eLearning):

• ELEARNING_ENTRY_URL — CAS entry point
• ELEARNING_IDP_BASE_URL — IDP base URL
• ELEARNING_ENTITY_ID — SP entity ID
• ELEARNING_TOKEN_PURPOSE — label for created tokens (default: "OpenClaw Auto Refresh Token")
• ELEARNING_CLEANUP_OLD_TOKENS — auto-delete old tokens with same purpose (default: false)

3. Run

# Full flow: login → create token → cleanup old tokens
cd scripts && .venv/bin/python elearning_login.py --cleanup-old-tokens

# Debug mode (verbose HTTP logs + save debug artifacts)
cd scripts && .venv/bin/python elearning_login.py --debug --cleanup-old-tokens

# Dry-run: only test up to public key fetch (no login)
cd scripts && .venv/bin/python elearning_login.py --dry-run --debug

On success, the script prints NEW_TOKEN=<token_value> to stdout.

4. Integrate with Token Lazy-Loading

For agents that call Canvas API, implement a lazy-refresh pattern:

1. Read saved token from file
2. Validate with GET /api/v1/users/self — check HTTP status only (don't read body)
3. If 200 → use token
4. If 401 → run refresh script, capture NEW_TOKEN=, save to file, retry
5. If refresh also fails → alert user (password changed, CAPTCHA triggered, etc.)

Key rules:

• Validate once per session, not on every API call
• Only re-validate on explicit 401 responses
• Don't log or expose raw token values
• The refresh takes ~2-3 seconds, run silently

Security

• .env contains credentials — never commit to git (.env is gitignored by default)
• debug_output/ may contain session cookies and encrypted payloads — sanitize before sharing
• The script uses PKCS1v1_5 RSA encryption for password transport (matching the IDP's JS frontend)
• Tokens are created with a purpose label for lifecycle management
• Old tokens with matching purpose can be auto-deleted to avoid accumulation

Known Limitations

Limitation	Impact	Mitigation
CAPTCHA/rate-limiting	Script cannot solve human verification	Alert user, manual intervention needed
MFA/2FA	Requires interactive flow not supported by requests	Not supported; alert user
IDP interface changes	JSON field names or HTML structure may change	Debug output (--debug) captures raw responses for diagnosis
Public key format changes	Script supports PEM, Base64-DER, modulus+exponent	If new format appears, extend parse_public_key_payload()

Troubleshooting

Run with --debug to save artifacts to debug_output/:

Symptom	Check
未能从入口响应中解析到 lck	debug_output/entry_response.html — look for context_CAS_...
queryAuthMethods 未找到 userAndPwd	debug_output/query_auth_methods.json — check moduleCode field
未从 authExecute 提取到 loginToken	debug_output/auth_execute.json — check code/message
未拿到关键会话 Cookie	Check auth_execute.json for errors, authn_engine_response.html for CAPTCHA
Token API returns 401/422	debug_output/cookies.txt for _csrf_token / _normandy_session
Cleanup fails	debug_output/cleanup_summary.json for failed entries

Adapting to Other Institutions

The IDP flow is based on a common CAS/SAML pattern used by many Chinese universities. To adapt:

1. Change URLs in .env: ELEARNING_ENTRY_URL, ELEARNING_IDP_BASE_URL, ELEARNING_ENTITY_ID
2. Test with --dry-run first to verify lck/authChainCode extraction
3. If IDP uses different auth methods: modify pick_auth_chain_code() in auth_session.py
4. If password encryption differs: modify encrypt_password_rsa() and parse_public_key_payload()

Tested with: Fudan University (id.fudan.edu.cn → elearning.fudan.edu.cn).