I am trying to authenticate a ruby on rails app through SAML with Azure Active Directory.
In the AD settings it is only allowing https not http URLs as the "reply url" AKA the ACS or Assertion Consumer Service.
My question is does the ACS url have to be over https, if so, is there a way to develop with an app on localhost?
For this specific issue, I always use tunnelling app https://ngrok.com/
Install and run
ngrok http 3000
Then you can use https
ADFS is somewhat specific and sometimes does not implement the SAMLv2 spec correctly (i.e. the IdP meta data has not been meta data schema compliant).
The ACS endpoint need not be secured on the transport layer, although SAMLv2 recommends this.
However as you might use a so called "frontchannel binding" (HTTP POST or HTTP redirect binding), why do you bother? The browser is doing the communiation, not the app. Only if you use a 'backchannel binding', like Artifact binding the App (acting as the SP) needs to talk to the IdP (not with the ACS in this case, but the "ArtifactResolutionService")
Related
I am planning to set up a CloudFlare proxy in front of my web service and use mTLS for authentication (see https://community.cloudflare.com/t/mtls-user-propagation/371991). Ths mTLS terminations is done by CloudFlare. What will arrive at my web server is an HTTP header called Cf-Access-Jwt-Assertion, containing a JSON Web Token (example can be found in above link as well) with claims.
Is there a way to configure Apache2 to verify this JSON Web Token for me so that my application does not have to?
This module would need to download through a given URL the public key of the JWT for verification, and would need to be configurable to verify certain claims in the JWT, e.g. the aud field or others.
Note: I am aware that a solution for HA Proxy exists, but I am explicitly looking for one for Apache2.
I have a web app developed using Create-react-app
I host it on IIS, the IIS only response to load the app, there is no server side logic on it (no Express or any other web server)
The app is using a RESTful API on the same IIS, it is out of my control (I cannot make change).
Now one of my client request to add SAML SSO to our app.
I would like to know:
in normal situation, which one is the Service Provider? My IIS Web server? or the API service?
For my case, I cannot implement SAML to API service, my web service only used to load my app without server side logic, how can I implement SAML?
Could any one give me some React implement SAML SSO tutorial or article for reference?
Thanks for any help, any information or suggestion are welcome!
in normal situation, which one is the Service Provider? My IIS Web server? or the API service?
I assume the client wants to authenticate the users using their internal IdP. So your application is the SP. But you will have to define different token service (details below).
With SPA (a single-page-applications) I see the problem, in SAML the user is redirected or posted away from the SAML request and SAML response.
I have a login page to enter id/pw, post them to API server Login endpoint to authenticate and get back a JWT token. After that we use that token in API calls for authentication
The API services are using a JWT token issued based on the provided username/password. I'd recommend to extend the token service (or use a different service) to issue a JWT token based on the provided SAML response - a token swap service. In many OAuth implementations it's called SAML grant type.
I cannot implement SAML to API service, my web service only used to load my app without server side logic, how can I implement SAML?
Usually after the authentication the user is redirected or posted to the SAML ACS endpoint URL, where the server can create sort of session (cookie, parameters, token, ..) and the user is redirected to a URL returned the web page with the session information.
If you are using an SPA, you could use a popup window or SAML with redirect (not with post), where the page could read the SAML response parameters (assertion, signature, ..) and use them in the token swap service mentioned above.
When processing the SAML response, try to use some mature, known, out-of-box libraries, it's a security service and not doing it properly may cause security weaknesses. But you need to do that on the server side, as at the end you need the JWT token consumed by the APIs.
We have a web application where the appThe lication is downloaded to the client using appcache and runnig int the client. It gets data into to via ajax calls. What it differes from the rest it we do not have a web server but the whole application is downloaded to the client is via an unauthenticated API call (via middleware server). Once the pages are downloaded to th client the login page is loaded and upon successful authentication the client will get a token for the session.
Now we want to secure this with SAML. But since we do not have a web server per say there is no way we can specify a URL (ACS) to redirect in SAML.
How do people implement SAML in this type of scenarios?
SAML only works through browser redirects.
You also have to have an IDP that supports SAML 2.0 e.g. ADFS.
The interaction is between the SAML application and the IDP. There is no 3rd party.
SAML is not ideal for mobile. OpenID Connect is a better choice. Either way, you have to add a client-side stack that supports the protocol to your application.
Also, SAML does not have a web API flow. OIDC does.
I am building a cross-platform mobile app that interacts with a RESTful API, and I want to use OpenID Connect to authenticate my users. I will be building my own OpenID Connect provider server.
OpenID.net claims that:
OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.
However, I can't find any documentation explaining how to actually authenticate for a mobile app client.
This StackExchange answer makes it clear that OpenID Connect does not support the "resource owner password-based grant" flow or the "client credentials" flow.
That just leaves the "authorization code" flow (normally used by server-side apps) and the "implicit grant" flow (normally used by client-side apps). Both of these seem to rely on redirecting the user to the provider's authorisation endpoint, and having the provider redirect back to the client URL. I don't see how this can apply to a mobile app.
Can anyone explain to me (or even better, point me at a tutorial or some example code) which explains how to do this?
Update
To clarify: OpenID Connect relies on the client redirecting the user to the Authorization Endpoint, and then the provider redirecting the user back to the client. In the case where the client isn't a web app, how can this work?
Mobile apps, at least on iOS and Android, can register custom URL schemes so that a redirect from a browser can send the user back to your app along with some query parameters.
So, you can use these flows in a native mobile app, but it involves sending the user to a web browser (either an external browser app or a web view built into your application) in order for them to authenticate with the OP.
A complete article presenting how to implement the "Authorization Code Grant" flow securely on a native mobile app is available here : Building an OpenID Connect flow for mobile. It is based on latest IETF OAuth 2.0 Security Best Current Practice.
Please also note that the use of the "Implicit Grant" flow is now highly discouraged.
I think that the Hybrid flow from the OpenID Connect spec is probably the one which you want to use. OpenID Connect Core Spec.
This does rely upon having a configured return URI, but as James says you would use a custom URI scheme to enable the mobile OS to redirect after login to your own app. Your app would then have an access code which it can use to obtain access tokens as needed (assuming that you are using Oauth2 to protect your back-end API services which the mobile app uses).
There is a vulnerability which would allow a malicious app to hijack your URI scheme and grab the tokens, There is a draft spec to overcome that Proof Key for Code Exchange by OAuth Public Clients which is worth considering implementing.
Using an app scheme URL is the correct answer as noted above. I wanted to add additional clarification since some responses above include links to an article that makes incomplete assertions about a compliant SSO design, and make it unnecessarily complicated for a simple SSO use case. I think google's model is secure and so I might model OIDC interactions with a homegrown IDP after how theirs works.
https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472
The design in this article linked above, as depicted in the diagram on the article, does not work for google's oAuth/OIDC implementation on Android. There are two reasons for this:
Google will not vend any client_secret for an oAuth client that is typed "Android"
Suppose I switch to "Web" application which does have a secret: Google will not allow a redirect_uri other than 'http' or 'https' for an oAuth client that is typed "Web"
Instead, google officially recommends letting the typical mobile flow (and you should also be using PKCE) drop an ID Token on the client, who can then exchange it for a session with the App server:
https://developers.google.com/identity/sign-in/android/backend-auth
This is secure because your IDP should be signing the JWT ID Token with a private key so it can be validated by your system's apps/services and used to assert validated (unexpired) identity intended for a particular OIDC client & audience.
** Do not pass ID Token as authorization on every request, but rather exchange it once with your backend for a secure session context as managed by your application.
Check out MITREid project on github:
MITREid Connect
This project contains an OpenID Connect reference implementation in
Java on the Spring platform, including a functioning server library,
deployable server package, client (RP) library, and general utility
libraries. The server can be used as an OpenID Connect Identity
Provider as well as a general-purpose OAuth 2.0 Authorization Server.
First of all, I am developing an AppEngine application. As framework, I am using jQuery Mobile. I use GMail API too.
To connect with GMail, I need to work with OAuth 2.0. I have set the credentials into my application (I already have client_secret.json into my project).
My situation is: I am in a JSP page when I call to my Java code (server side) to get my Gmail Service. For this task, I need to get the permissions (Oauth 2.0) from my user. Later, we need to redirect to my application.
My problem is what I do not know what I have to write exactly in "AUTHORIZED JAVASCRIPTS ORIGINS" and "AUTHORIZED REDIRECT URI".
I am testing my application in local mode and the normal URL is: localhost:8888/mobile/index.jsp
Can you help me?
Best regards,
Diego.
Details here
AUTHORIZED JAVASCRIPTS ORIGINS -> Protocols (ie HTTP and HTTPS) and domains (my-app-id.appspot.com) that can use JS and OAuth calls. For local add
http://localhost:8888/
. You will need to add one for the production URL as well.
AUTHORIZED REDIRECT URI -> When doing OAtuh calls from the app it needs a handler setup to get responses from the OAuth server. Personally I use decorators, so my redirect URI is
http://localhost:8888/oauth2callback
. Yours will vary depending on how you handle the OAuth flow.