A federated user in a city tenancy has a valid auth token but docker login to OCIR still fails. The Profile menu shows an identity-provider path such as oracleidentitycloudservice. What username shape should they use?
Select an answer to reveal the explanation.
Short Explanation
Federated logins add the identity-provider path between namespace and username. Skipping that segment often looks like a bad password even when the token is fine.
Full Explanation
Federated users authenticate to OCIR with a three-part Docker username: <tenancy-namespace>/<identity-provider>/<username>. The middle segment is the identity-provider path shown in the Console Profile menu (for example oracleidentitycloudservice). Inserting that segment between the Object Storage namespace and the username is required so OCIR can map the auth token to the federated principal. A valid auth token alone does not compensate for a username that omits federation context.
Omitting the namespace and using only the identity-provider name drops the tenancy context OCIR expects. Using the simple <tenancy-namespace>/<username> form and ignoring federation is exactly the mistake that often presents as “token is valid but login still fails” for federated city tenancy users. Replacing the auth token with the identity-provider metadata URL as the password confuses SAML/OIDC discovery metadata with a Docker registry credential; the password must remain an IAM auth token.
Exam caveat: identity-provider names are case- and spelling-sensitive—copy them from the Profile path rather than guessing. Operational check: from the user’s Profile menu, note the IdP segment, construct the three-part username, docker login with the auth token, and only then troubleshoot repository IAM if login succeeds but push/pull still fails.