Is it possible to have SSO across multiple apps, installed through MobileIron, that connect to back-end services/sites protected by SiteMinder or any custom authorization provider ?
Looking at this Stackoverflow discussion and MobileIron video, it seems like the MobileIron SSO can be against KDC only.
As far as I know, you're quiet right: SSO capabilities to Intranet applications located behind MobileIron Sentry are provided via KCD. The possibility to do this via user certificates managed through MobileIron seems not to work (look at this thread iOS Client Certificates and Mobile Device Management).Third party / custom authentication providers like SAML are not supported at the moment by MobileIron.
Related
I have been looking into using an identity provider (IDP) to provide user authentication for a Windows Forms client. The user credentials will be hosted by Auth0. After creating a trial account with Auth0 I have downloaded a sample C# Windows Forms client application that can be used to authenticate to the Auth0 IDP using OpenID Connect ("OIDC"). The WinForms sample application pops up a web browser component, displays the Auth0 login screen, I login to the Auth0 IDP (having setup some test credentials in Auth0) and the WinForms application then is sent an authentication token. All well and good, and if I try to login a second time I no longer need to enter my credentials.
However... the company that I will be fetching authentication data from in production would like to use SAML. Is there any way to do this? Based on what I have read, SAML needs a "Service Provider" that will receive credentials from the IDP. The Service Provider is (typically?) a web site. That does not seem to match very well with what I am trying to do (authenticate a windows client). Is there any way of using SAML to do essentially what I have done using OIDC (fetch authentication information for a user from an IDP)? Would I need to develop a separate Service Provider component for this?
Sounds like what you've done so far is fine architecturally:
A modern desktop app following OIDC standards
This puts you in a good position architecturally, where:
Your app gets tokens from Auth0 using OIDC
Auth0 can reach out and do federated authentication with other standards based identity providers, which could be SAML, OIDC, WS-Federation or anything else
This can be done without changing any code in your app - and your app does not need to understand SAML
Feels like you need to set up a federated connection from Auth0 to the SAML Service Provider, and most commonly this involves these steps:
You give the partner your Entity Id and Response URL, to post tokens to
They give you am Entity Id, Public Key Certificate and request URL
You configure rules around account linking, so that users can be matched between their system and yours
There are prerequisites though, and the external identity provider needs to be SAML 2.0 compliant. My Federated Logins Article may help you to understand the general concepts, though I do not drill into SAML details here.
I am trying to integrate Salesforce with AAD, so I see two available options, either Saml or OpenId Connect.. I do not know which one is better, but I prefer OpenId Connect since it seems to be more modern. So I tried to register Salesforce App in AAD and Saml was the default options, so why is Saml the default option ?! is it better or what? Please note that I am building an API and I need to allow authentication and authorization with Single Sign On.
The Azure AD app gallery contains many popular applications that are already pre-configured to work with Azure AD as an identity provider. These applications will be available in the Enterprise applications and have SAML to perform SSO. Any application which is added directly from the Gallery the default method is SAML based SSO , password based SSO etc.. which depends upon the applications.
Kindly check the difference between the App Registration and Gallery application in Azure portal from the link
In order to get more detailed explanation about SSO types and protocols kindly check the document to get more detailed explanation.
If you have any further queries kindly let me know.
I am working on a project where we are planning to use SAML 2.0 to send authentication requests to OpenLDAP. Can someone please tell me if its supported or not? I am not able to get the clear answer via Google.
SAML and LDAP are completely different things. SAML is mostly used for Web-based SSO. The identity provider (IdP) part of the access manager software/system you're using (i.e., the one that implements SAML authentication authority) may use a back-end LDAP server (e.g., OpenLDAP) for authenticating users.
I am using a SaaS application and I want to use our own LDAP to Login to that 3rd party application. I want to provide a link to that application in my Portal. Both the applications are hosted in Cloud and are Spring based.
Please let me know where to Start and how to go about implementing SP initiated SAML.
Thanks!
First of all you need a SAML IDP that authenticates against LDAP e.g. shibboleth.
Then you need a client side SAML stack.
Refer: SAML : SAML connectivity / toolkit.
You could also look at IDaaS e.g. Auth0 or Okta.
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.