Actions
Workbench authentication process » History » Revision 16
« Previous |
Revision 16/26
(diff)
| Next »
Peter Amstutz, 11/17/2014 09:08 PM
Workbench authentication process¶
- In workbench, when the browser goes to a page, it checks for a session or
?api_token=xxx
in the URL for the API token. If no API token is found, the brower is directed to the workbench "welcome" page. - In workbench, the "welcome" page has a "log in" button that directs the browser to the API server login URL, with a
?return_to=xxx
link embedded in the URL. - In API server, the 'login' endpoint goes to
UserSessionsController#login
in the API server. This redirects the browser to/auth/joshid?return_to=xxx
- In API server,
/auth/joshid
is intercepted by the OmniAuth Rack middleware and invokes thejosh_id
OmniAuth strategy.- The
josh_id
OmniAuth strategy is implemented inarvados/services/api/lib/josh_id.rb
and is a subclass ofOmniAuth::Strategies::OAuth2
- OmniAuth starts the "request_phase" of
OmniAuth::Strategies::OAuth2
. This redirects the browser to#{options[:custom_provider_url]}/auth/josh_id/authorize
using CUSTOM_PROVIDER_URL defined inarvados/services/api/config/initializers/omniauth.rb
- The
- In sso-provider,
/auth/josh_id/authorize
is routed toAuthController#authorize
, and is intercepted bybefore_filter :authenticate_user!
(part of the devise gem)devise :omniauthable, :omniauth_providers => [:google]
configuressso-provider/app/models/user.rb
authenticate_user!
is not explicitly defined but instead monkey patched into the controller indevise/lib/devise/controllers/helper.rb
authenticate_user!
callswarden.authenticate!
(warden/lib/warden/proxy.rb
) with a scope of:user
(warden is another Rack-based authentication gem)- Warden proxy tries the TokenAuthenticatable and DatabaseAuthenticatable strategies, but these strategies fail and it raises a :warden exception. This causes it to call
failure_app
which is set up indevise/lib/devise.rb
to beDevise::Delegator.new
- This calls
devise/lib/devise/failure_app.rb
which saves the attempted path in the session ("user_return_to") usingstore_location!
, then redirects the browser tonew_user_session_path
(/users/sign_in
)
- In sso-provider
/users/sign_in
routes to the SSOSessionsController#new
which subclassesDevise::SessionsController
SessionsController#new
redirects the browser to/users/auth/google
- In sso-provider, OmniAuth intercepts
/users/auth/google
- OmniAuth is configured with a path prefix of
/users/auth
by devise sso-provider/config/initializers/devise.rb
configures a:open_id
omniauth strategy named of 'google'- This enters the request phase at
omniauth-open-id/lib/omniauth/strategies/open_id.rb
- This creates a rack layer with
Rack::OpenID.new
(therack-openid
gem) executes it withcall
- The Rack layer passes through the request to the underlying
@app
and checks for a 401 response code, if so it callsbegin_authentication
begin_authentication
constructs an::OpenID::Consumer
object and calls redirects the browser toopen_id_redirect_url
, which finally takes us to a Google login page (after some redirects within Google).
- OmniAuth is configured with a path prefix of
- Google presents the user with a login page, and directs the browser to the sso-server at
/users/auth/google/callback
after a successful login (after more redirects within Google) - In sso-provider, Omniauth intercepts this and calls
callback_phase
in omniauth-openid- The callback phase calls
openid_response
openid_response
creates a rack layer withRack::OpenID.new
(therack-openid
gem) executes it withcall
. This provisions the Rack environment with info from the OpenID callback.- Request handling continues to sso-provider where it routes to
Users::OmniauthCallbacksController#google
- This calls
find_for_open_id
on theUser
model which finds a user record with a matching identity url, or creates and saves a new user record with the identity url. - The
google
callback also saves the first_name and last_name of the user. - This calls
sign_in_and_redirect
defined indevise/lib/devise/controllers/helpers.rb
- This calls set_user in Warden, which uses
Warden::SessionSerializer
to save the user associated with the session - This redirects the browser to
stored_location_for
which returns the value ofuser_return_to
in the session, which is/auth/josh_id/authorize
from step 5.
- The callback phase calls
- In sso-provider,
/auth/josh_id/authorize
routes toAuthController#authorize
, and passesauthenticate_user!
because the there is now a user associated with the session.authorize
builds anAccessGrant
using thestate
token from the requestauthorize
redirects the browser toparams[:redirect_uri]
which is/auth/josh_id/callback
(this is the oauth callback on the API server, saved from step 5)
- In API server,
/auth/josh_id/callback
is intercepted byOmniAuth::Strategies::OAuth2
and callscallback_phase
.OmniAuth::Strategies::OAuth2
creates a::OAuth2::Client
and callsget_token
to convert the "authorization_code" into a "oauth_token"- The API server makes a request to the sso-provider at
/oauth/token
- In the sso-provider,
/oauth/token
is routed toAuthController#access_token
- This first checks
Client.authenticate
which verifies thatclient_id
(app_id
) andclient_secret
(app_secret
) are recognized - Next it calls
AccessGrant.authenticate
which verifies thatcode
andclient_id
are recognized - This renders an JSON API response with the
access_token
,refresh_token
andexpires_in
fields which are returned to the API server.
- This first checks
- The API server, back in OmniAuth::Strategies::OAuth2, receives the response and saves the
access_token
.- Request processing continues and routes to
UserSessionsController#create
- API server gets the OmniAuth object and looks up the Arvados API user by
identity_url
- The session is provisioned with the Arvados user id
if params.has_key?(:return_to)
then it callssend_api_token_to
send_api_token_to
creates a new ApiClientAuthorization- It redirects the browser to the
:return_to
after addingapi_token=xxx
to the query portion of return_to
- Request processing continues and routes to
- The browser is finally redirected to workbench to with
api_token=xxx
- Workbench adds the api_token to the session, and redirects the browser one last time to the same location with
?api_token
stripped from the query portion.
- Workbench adds the api_token to the session, and redirects the browser one last time to the same location with
Questions¶
- What is workbench's "secret_token" for?
Updated by Peter Amstutz almost 10 years ago · 16 revisions