I am evaluating SSO solutions and am currently looking at OpenAM and JOSSO2
I am -extremely- new to SSO, OpenAM, JOSSO2 and am just now trying to learn what I need to learn.
My application will need to be able to authenticate users against at least two different identity stores.
A local Database Store (Oracle, and to begin just a simple user/pass)
Active Directory (with x.509 two-factor authentication requirement)
There are two classes of users, which would authentication against one or the other (and NEVER both).
It is possible to setup OpenAM or JOSSO2 to be able to handle such a scenario? In a previous job (life) I worked on a system that used JOSSO_1_ to accomplish this, but I am hoping for a more refined approach (e.g. less custom code) to this current product.
Identity stores are different from 'source of authentication' in OpenAM.
OpenAM offers a wide range of different authentication modules and also allows to use JDBC or LDAP as an implementation of a user data store.
Furthermore authentication as well as data store API is extendable, allowing to plug in your specific implementation if needed.
Related
I'm developing an ASP.NET Core API, and I'm trying to do the authentication and authorization part as best as I can. I'm studying OAuth 2 and OpenIDConnect (very preliminary studies at this point). But from an API developer standpoint, what can I gain from inserting an Identity Provider like Auth0 or Azure AD B2C in the process instead of just storing the user credentials using some form of cryptography?
Also, Oauth 2 seems to allow many flows, is the job of the API to be concerned with the flow of the application consuming that API? Seems a bit unreasonable. What I want is just to have a safe way to store the user credentials, and allowing the users of my API to perform authentication and authorization before consuming and manipulating resources within the other services within the API.
I understand that authentication and authorization is a sensitive topic within an application, as they deal with security concerns, and I'm planning on building an application that will deal with sensitive financial operations. That's the reason I wend after Auth0 and Azure AD B2C. But to be honest I'm having a little trouble trying to understand what Identity Providers like these will bring to the table, I know they'll bring something of importance, I just need some help to see what and why should I use them.
what can I gain from inserting an Identity Provider like Auth0 or Azure AD B2C in the process instead of just storing the user credentials using some form of cryptography?
Well, you get the freedom of not storing credentials in your database.
Most likely these service providers are taking better care of their security than you would.
Another thing that you gain is Single Sign On.
Many apps can use the same identity provider for the users, so the users only need to sign in once to use all of the apps.
Of course it is not zero cost, there is complexity involved in OAuth/OIDC.
But neither is building your own user store.
Also, Oauth 2 seems to allow many flows, is the job of the API to be concerned with the flow of the application consuming that API? Seems a bit unreasonable.
No, the API usually does not care what flow the caller uses.
What it cares about is that it receives a valid access token that contains the necessary permissions to access a particular resource.
It is a concern of the client app to choose the flow to use.
But to be honest I'm having a little trouble trying to understand what Identity Providers like these will bring to the table, I know they'll bring something of importance, I just need some help to see what and why should I use them.
Well, here are the things that come to my mind:
Better security (most likely, it isn't only about the password hashing algorithm etc.)
Better SLA (building a 99.95% SLA service like Auth0 is not cheap)
Proven track record
Single Sign-On
Single identity for users to all your apps, can easily disable their account as well to prevent access to all apps at once
Can easily add support for federated authentication with other identity providers
No need to store password hashes etc. in your app
Ready-made administration tools (which you need to build otherwise)
To add to #juunas:
AI to proactively monitor user access and disable dodgy logins e.g. logging in from USA and Russia a minute apart
Reporting and stats.
Password protection e.g. not allowing password that has appeared in a breach
Portal and API for user CRUD
MFA
Self-service password reset
Passwordless support
Fido 2 support
Currently my organization uses a number of web apps/mobile apps/APIs, some of which authenticate against an in-house IdP and others which use a third-party proprietary system (over which we have no control).
We have been asked to implement SSO for these web applications and as a result I have been reading up on OpenID Connect. I believe this would be a better solution than SAML given that (a) end-users are not always enterprise users, and (b) SAML not designed for mobile applications.
I believe I understand the flow reasonably well but have one sticking point. To allow users to authenticate using an external IdP, we would need to map the user back to our internal id. For example, user authenticates using OIDC/Google, resulting in us receiving the user's unique Google idenitifer (and email etc if we queried further), but this is not useful to us until we can map the Google identifier back to our internal customer id.
Is this mapping out of scope for OIDC? If so, is there a best-practice method for doing this? I'm sure we are not alone in this requirement...
Thanks,
John
Is this mapping out of scope for OIDC?
Short answer, yes.! If your backend require a comparison/validation with internal identity details, then it has to be done out-of-scope of OpenID Connect(OIDC) protocol. OIDC simply define the process of obtaining tokens (ID and access token), which are required for authentication and authorization.
is there a best-practice method for doing this?
One option is to use out of band directory synchronization. For example, Google provider Google Cloud Directory Sync (GCDS), which allows you to synchronize identity details to LDAP or MS Active directory. Other alternative is to use SCIM protocol to communicate and provision users dynamically. For example Google provide that support as well.
Alternatively, you can use just-in-time provision at the time you receive tokens. This support will depend on your identity provider implementation. For example, WSO2 identity server support both JIT provisioning as well as SCIM.
I am researching different Single Sign On options. It seems to me that SAML while is a great solution if we look at 3rd party vendors it is somewhat out of our price range. We are also looking at implementing our own solution... but, some of the services we want to use - just to enable SAML logins they want to charge. If I know all of my user's credentials what is the security risk/downside of just doing an HTTP POST with the credentials to these different services? Some of the SSO providers do this when SAML is not enabled as well.
Using SAML would remove the need for users and Service Providers to deal with password issues like reset, expiry, recovery, rotation etc. completely, aside from managing the synchronization process that now needs to happen between IDP and SPs.
In addition to that there's the the amount of brittle, costly and awkward reverse engineering of SP login webpages that needs to be done and maintained(!) by any IDP that operates a password vaulting system (which is what you describe).
Also, introducing an SSO system allows you to concentrate user authentication efforts and improvements in one place only, making it simpler to introduce strong or second factor authentication for all services at once, without requiring support for that by each SP.
Last but not least: password vaulting systems still involve passwords that are distributed over different systems/SPs and that cannot be (completely) hidden from the user. That makes it hard or impossible to ensure that access to all systems is turned off at once e.g. when a user leaves the organization.
I have a question regarding ADFS and forms authentication. I currently maintain a database of users and have built a somewhat complex claims-based system around it. All of my clients use forms authentication to access my website (ASP.NET). Recently one of my clients expressed a desire to switch to a single sign on model. I would like to use ADFS to accomplish this. My question is how do I go about using both forms authentication and ADFS at the same time. I need all of my other clients to still be able to access the site using forms authentication. I know this cannot be a rare problem, but I can't seem to find any good answers to the question. Thanks very much.
using ADFS V2.0 allows both types of authentication, windows and forms and both relies on the active directory that means you must save and keep all the users data in the active directory.
pleases see http://www.richardawilson.com/2010/10/adfs-20-login-page.html
if you need the ADFS reads the users and credentials from another source than the Active directory,
in that case you must implement a custom claim provider and configure the ADFS.
Not sure I totally understand the question but ADFS can use FBA - AD FS 2.0: How to Change the Local Authentication Type.
Is your "complex claims-based system" a STS? If it is, just federate with ADFS.
If it isn't, have a look at Thinktecture IdentityServer.
Curious what recommendations anyone has.
I have an existing asp.net forms application that does a Forms Authentication and has identity impersonate turned on.
The application has a link to a questionnaire that I would like to develop separately in an asp.net MVC application, but I don't want the users to click on the link and be prompted for a username and password, I would like them to be able seamless start filling out the questionnaire.
Is there a way to somehow transfer authentication from one .net app to another? I would like to be able to pass stuff like UserRole.
What's the best way to do this?
If you use the same MachineKey in both applications and the MVC application is on the same server, I think that it will reuse the auth cookie and simply consider them logged in. See this MSDN article on configuring the MachineKey, especially the section on sharing authentication tickets across applications. Note this assumes that both applications are on the same server. If they are on different servers then you'll need to investigate some other mechanisms -- say generating a single-use ticket for the URL that can be used by the remote system via a web call back to the originating server who the user is. It might not need to be a full-up implementation of a central authentication system, but along those lines. Just be sure that you're using SSL to encrypt the relevant bits to help avoid man-in-the-middle attacks.
Using Windows Identity Foundation (WIF) you can achieve Single Sign-On.
In WIF, a service called a Security Token Service (STS), issues a token with claims, which can be anything you want to declare about the authenticated user, for instance his roles. In your apps you can use the Page.User, Controller.Page or Thread.Current.Principal properties to check the User claims (though if you'll only be using role claims you can use the IsInRole method for simplicity).
You can easily create a STS using the tools for VS included in WIF's SDK. The Forms authentication will be done in the STS instead of in the Web Forms site and both sites should have a trust relationship with the STS.