{"push_id":1101441646,"size":1,"distinct_size":1,"ref":"refs/heads/saml_fixes","head":"8a4d19938c05245bd2da4b9971baec37f6081aac","before":"127ab6f6543e14a5dd12fdfd1b7c3ca6b0e605e6","commits":[{"sha":"8a4d19938c05245bd2da4b9971baec37f6081aac","author":{"email":"d3b0f0e000766789d555671db126f879c81655c5@cnelson.org","name":"Chris Nelson"},"message":"[WIP] Fix ambiguous SAML workflows\n\nWhen migrating from UAA auth to an external SAML IDP or when operating in a multi-IDP environment it is common to have users who\nstart out as UAA user and then later need to be transitioned to an external IDP.\n\nUpdating the user to use an external IDP for auth is as simple as making a PUT to /Users to update the 'origin', however the\nuser experience for user during and after the migration can be confusing.\n\nThis commit attempts to make the SAML authentication workflow more explicit:\n\nScenario #1: The IDP sends a valid SAMLResponse for a user not in the UAA database:\n\n        If addShadowUserOnLogin is true then we create a new user (current behavior unchanged).\n\n        If it is false, we display the saml_not_invited template where we can provide detailed information on how to request an account.\n        (current behavior is to display a page with nothing but the sad cloud image and their username displayed)\n\nScenario #2: The IDP sends a valid SAMLResponse for a user in the database who's origin is UAA and not the IDP:\n\n        If addShadowUserOnLogin is true, we treat it the same as Scenario #1 and create a new user.\n\n        If it is false, we display the saml_dupe template where we can instruct the user to contact an administrator to resolve this issue.\n        (current behavior is to display a page with nothing but the sad cloud image and their username displayed)\n\nScenario #3: A user doesn't know they've been migrated and attempts to login with their user/pass\n\n        Current behavior is to display an ambiguous 'Unable to verify email or password. Please try again.'\n\n        To fix this, we replace the default AuthenticationFailure handler with one that checks the domain of the username who's failed to login and\n\n        If we have a SAML IDP registered for that domain, we redirect the user to the IDP's login workflow.\n\n        If there is no IDP for that domain, or the username does not contain a domain we continue the current behavior.","distinct":true,"url":"https://api.github.com/repos/cnelson/cg-uaa/commits/8a4d19938c05245bd2da4b9971baec37f6081aac"}]}