I have to authenticate user either by saml or by database credentials depending on how user wishes to get authenticated .
I am stuck with two problems
1)I am receiving the saml response to the call back back url. I am not sure how to integrate it with devise.
2)I am not sure how to authenticate the user either by database or by saml response dynamically based on user choice.
Any suggestion would be really helpful
You will have to use a WebView to embed the logon page in your App.
If the user chooses Database logon you will have to challenge the user to submit their user name and password. Once the user is identified by your API, your business logic will be kicked in.
If the user chooses SAML login, it will be federated login and you will send the Authen Request to the Idp. The Idp page will be rendered in WebView within your app. Once the Idp will identify the user after logon process, they would redirect the page to the URL as specified in your Authen request for the attribute AssertionConsumerService. You will have to intercept the Request to extract the SAML token which you will have to eventually submit in a API service in your environment. The API service will have to do the token processing and will generate a User profile that is identical to the one generated by the database authentication.
I recently implemented SAML with Devise in my application, and found that the omniauth-saml gem is the quickest route to getting it to work. It will handle your callback flow, usage of the ruby-saml library, and all the other details that would be a pain to implement on your own. And if you need to handle an arbitrary number of SAML providers, omniauth-multi-provider-saml worked well for me.
Related
Does ORY Hydra currently have a feature that verifies if a client is logged in via OpenID Connect? I notice there is an API to logout via front-channel
When a user revisits the identity provider, however, I have no way of knowing if they are currently logged in or not. They could delete their client-side HTTP cookies and then I am out of sync with Hydra. Meaning: Hydra has them as logged in, but I have them now as logged out. Also, in the event of a back-channel logout, I want to be able to query for this state.
Is there an API I am overlooking that allows me to know whether a client currently has an active OpenID Connect login via Hydra?
It appears as of right now the only thing one can do is redirect the user to the authorization endpoint since we have no way of knowing if they are authorized or not.
The following two tables that ship with Hydra seem to be the source of truth for the data I am after: hydra_oauth2_access and hydra_oauth2_authentication_session. Does it ever make sense to query those directly if there is no supported HTTP API out of the box to see if a user has an active authentication session?
Sending an authentication request via a redirect to the Provider including prompt=none addresses this use case: it will silently login and return new tokens if there's an ongoing SSO session at the Provider, it will return an error code login_required if not.
Notice there will never be explicit user interaction in both cases so this is convenient (and meant) to run in an hidden iframe.
LOGGED IN STATE
An OAuth client is most commonly a UI application with multiple users. Each user's logged in state is represented by an Authorization Server session cookie that neither the application or user have access to:
The Authorization Server (AS) issues an SSO cookie, to be stored in the system browser for the AS domain
Both Web UIs and Native UIs send it implicitly on subsequent requests, when they invoke the system browser
AUTHORIZATION REDIRECTS
When an OAuth UI redirects the user, it is generally unknown whether:
The user will be prompted to login
The user will be signed in silently (eg the user could have signed in to another app)
For a Web UI it is possible to send an authorization redirect on a hidden iframe with a prompt=none parameter. If the user needs to sign in a login_required error code will be returned. See my Silent Token Renewal Page for further details.
This is not fully reliable however, and has some browser issues in 2020. Also it may be unsuitable if you are using a different type of client.
FEDERATED LOGINS
In some setups the AS redirects further to an Identity Provider (IDP), and the user's login state is further influenced by an IDP session cookie.
There is no way for an app to get hold of the user's IDP login state, since the app only ever interacts with the AS.
IS THERE A USABILITY PROBLEM?
If so, post back and we can discuss further ...
I'm building an app that requires users to authenticate with Salesforce. However, the problem I'm encountering occurs when Okta (SSO) steps in to authenticate the user automatically. The user is authenticated and redirected to the Salesforce home page, rather than the OAuth callback redirect as configured in the connected app (and passed as query param).
This is happening between steps 3 and 4 on this diagram:
Question: Is there a way I can prevent Okta from automatically authenticating a user on a page?
Just wanted to circle back and post my answer. It was simply the authorization server url. Instead of directing a user to a specific Salesforce instance (i.e., "na17.salesforce.com"), use the Salesforce auth server (i.e., "login.salesforce.com"). This keeps Okta from identifying the specific subdomain and trying to authenticate.
Im a bit stuck. I dont know how to setup ember-simple-auth with my current rails + ember-cli app.
Currently, the user has to login with steam, so they get redirected to steam's login page. When they press authorize, they get redirected back to my site. I then let rails process the request and if they successfully signed in with steam, I set a cookie with a randomly generated token.
Now I need to do two things for ember-simple-auth.
Tell ember-simple-auth to check if the token exists, and if it does, make an api call to get the user's infor like the name, email, username, etc...
Add a prefilter that passes the token in most requests.
For #2, I can just use the OAuth authorizer, but for #1, I have no idea.
Thanks.
You need to implement a custom authenticator and use that to authenticate the session in an initializer when the app starts. The authenticator would in its authenticate method read the token that the Rails app writes to the cookie, make the API call and resolve with a bearer token that the OAuth 2.0 authorizer would then inject into requests.
I am in the process of designing an app that is supposed to let you login using either a username/password combination or facebook login. We have a custom OAuth server that uses user credentials to authenticate users. Now, the question is how to add facebook into this.
As I see it now, when the user wants to login with facebook, the client does all the work and gets the access token in the end. But how do we let our server know that this access token is a good one (and corresponds to a user in the database)? To me it seems like our OAuth server should be able to handle this as well, and I'm just missing the how.
OAuth supports different scenarios (flows). Client-does-all-the-work is so called "implicit" flow.
In your case it would be better to use authorization-code flow and extend your OAuth server. You put a "Facebook" button on your login page and instruct Facebook to redirect to a new special page on your OAuth server. Delivered authorization code then can be exchanged to the access token inside of your OAuth server and the server may issue its own session and tokens based on this.
I'm creating an MVC web site, and I want to mix forms authentication (the built in authentication) with Twitter authentication in my site (eventually it will have Facebook/Google authentication too).
The approach I'm taking is this:
- I let the logic to create users and validate users/passwords from the Forms authentication as it comes out of the box.
- I created a new users table where I save the name of the user, the id of the user in my site and the authentication service of that user ("Forms", "Twitter", "Facebook").
- When the user logs in using any of the authentication methods, I create a standard Authentication cookie, adding the user id and authentication service to the UserData of the cookie.
Now, I want the user to be able to stay logged in after he closes the browser, no matter which service the user used to log in. With this I mean, that if the user opens the site again, he won't have to authorize Twitter again on the site.
Right now, with the cookies approach, MVC loads the user information from the cookie and the user seems logged in when he enters the site, exactly what I want.
The problem is that if the user revokes my site's access, the user's authentication cookie will still be valid, and the user will appear as logged in, even though the authorization for my site was revoked.
My question is, is there a way to validate the authorization in the moment MVC loads the information from the authorization cookie?. I know I can use a custom AuthorizeAttribute and validate this on the AuthorizeCore method, but this will be invoked only when the user is accessing a ActionMethod that requires authentication.
Thanks for your help.
Write an HTTP module that implements IHttpModule and handles the HttpApplication.AuthorizeRequest event.