I was just playing around with OpenAM and found that authentication can be done through SAML as well as cookie based approach of CDSSO. Now my concern is if I am working in domain like banking and healthcare how feasible it would be to go for CDSSO cookie based approach and is their any organization who is practicing cookie based approach in any such domain.
SAML is designed for connecting independent security "domains". The term "domain" in this instance has nothing to do with network domain names, but a rather more nebulous term, meaning a division between security systems. An example to explain a bit better: Company A uses OpenAM to protect its intranet websites, but they also use services from Salesforce. SAML is the obvious choice here - Salesforce isn't going to use a cookie from OpenAM... How could they? You could also use it to interconnect two different systems inside a company (and domain name), like OpenAM and Siteminder, since those two systems can't communicate directly via their cookies.
CDSSO is primarily designed for use inside an organization that could have multiple domains that they protect. They can have multiple policy servers in multiple domains, but all of those servers are managed by the same OpenAM instance, and they all share a common backend. Lots of organizations use OpenAM's (and OAM's, and Siteminder's) CDSSO capabilities. But they use it inside the systems within their control.
In addition, I can't think of a single service provider that would want you to place one of your OpenAM policy servers inside their network. You wouldn't want them touching your server, and they wouldn't (if they are right in the head) trust you to not be dropping a trojan in their network.
TL;DR:
SAML - outside of an administrative domain
CDSSO - inside an administrative domain
SAML is the standards based way of achieving SSO for, Agents is the proprietary way.
SAML does not offer any authorization (which user is allowed access to a given resource) out-of-the box ... that's the backdraw.
Related
I'm planning to federate external Identity Providers (Google,Microsoft,GitHub,...) to my applications.
In my applications for security reasons we want MFA to be enabled for every user.
Is there any way to detect if the user authenticated himself using "Google" with MFA?
I understand that federating an external Idp, the user identification responsibility is transferred to the external Idp, so I doubt that what I'm asking would be possible.
Thanks in advance.
OaicStef
P.S.: In my applications, I manage the authentication with Identity Server 4.
The amr claim is what you're looking for but it's optional so it's not for certain that all providers will provide it and if they do they may provide the data in different ways - e.g. one might return ["pwd","otp"] to describe a situation where a password and a one-time code were used and another may just just use "mfa".
The best thing to do would be to experiment and observe what each service does both with and without MFA enabled and adapt as neccessary.
If it's not something you can guarantee then there's also the option of implementing your own MFA features - libs for using TOTP-based authenticator apps or FIDO2/WebAuthn are readily available.
I am quite confused about setting up SAML SSO for an application in Azure Active Directory.
I already have SAML metadata downloaded from the "general" endpoint https://login.microsoftonline.com/[Unique_ID]/FederationMetadata/2007-06/FederationMetadata.xml
However, when I configure my application in AAD, it sets up a signing certificate for the application and there is another link to SAML metadata, which slightly differs from the first, "general", metadata:
The general one contains 3 signing certificates, while the concrete application-specific metadata contains just one: the certificate configured especially for the application on AAD side. The application-specific certificate in not any of the 3 certificates from the general metadata.
The general one is digitally signed, the specific one is not.
Both have the same Entity ID.
I am quite confused about this concept, I haven't seen it on any other IdP server yet. I have already realized I must use the application-specific metadata to configure my Service Party, otherwise the digital signature of SAML assertions will not be verified.
So, my questions are:
Why does AAD provides the option to have application-specific signing certificates and SAML metadata? Why can't I simply use the global metadata/certificates and have all assertions for all applications signed with the same certificate?
Is it somehow possible to disable this feature and only use the global metadata for all Service Parties? The benefit would be clear: having just one IdP metadata instead of N.
Why does AAD provides the option to have application-specific signing certificates and SAML metadata?
One reason this is useful is that you control the certificate rollover. (Not all apps are "well-behaved" and deal correctly with planned certificate rollovers.)
Is it somehow possible to disable this feature and only use the global metadata for all Service Parties?
Sort of.
If you create a new App registration (as opposed to going via Enterprise apps > New app > Custom app), you can do SAML 2.0 against that app, with the details exposed in the "global" federation metadata.
The downside to this approach is that you won't get access to the Enterprise Apps > (app) > Single sign-on section, so you won't be able to do things like choose which attribute is used as the NameID, or have a UI interface to do claims customization (though you can still do custom claims mapping policies).
We want to build a central authority to do authentication and authorization for our various applications (.net). We see IdentityServer4 is open source and free, while Auth0 cost money. Does anyone use both of these? Can anyone provide suggestion which one to choose and why?
IdentityServer is a library that implements various authentication (not authorization!) protocols and let's you consolidate access control into a single system. You can host it in a typical ASP.NET webapp, console app or anything else, as long as the HTTP endpoints are available. It also lets you store the user data anywhere you want, whether in-memory, databases, flat files, the asp.net core membership system, or anywhere else.
Auth0 is a company that provides a managed service that handles authentication for you. They run the infrastructure and provide access through their website and APIs. It's similar to having someone run IdentityServer4 for you and there are several competitors like Okta for Devs, AWS Cognito, Azure AD B2C, Google Cloud Identity/Firebase, and more.
Choose IdentityServer if:
You want free open-source software.
You have the time and effort to run it yourself.
You want to control the backing data store (SQL database, Redis, JSON file, etc).
You want to manage all the data yourself due to regulations, privacy, etc.
You need complete control and flexibility around what happens during authentication (for example, merging user accounts in your database when someone signs in). It's all just C# code so you can do whatever you want.
Choose Auth0 if:
You want to save time and effort on implementation and operation.
Price is not an issue (as it can get expensive for some features).
The limited customizations offered by Auth0 are enough for your app.
You want the other features they offer like password-breach monitoring.
You don't want to manage user data, or don't mind having it stored by them.
Update as of Oct 2020 - IdentityServer is now a product from Duende Software with a new commercial open-source license to sustain development. There are other alternatives like OpenIddict that are still free.
Identity Server means building a server application to handle authentication and authorization, which can replicate what Auth0 does for OpenIdConnect (OIDC) there will be a few things to implement even if you use IdentityServer4. You will need to build that first, then integrate your application.
Auth0 allows you to integrate immediately with OIDC with additional & enterprise features.
Both of them implement federated protocols i.e. WS-Fed, SAML and OpenID Connect.
In order to use them your apps. need the appropriate client-side stack.
If they don't have this, you can't use the products.
The only alternative is pass-through, i.e. Auth0.
Or look at ADFS which has pass-through via the ADFS WAP.
If you do have the stacks, both will do the job.
idsrv4 does not have a user management portal e.g. create user, add group to users OOTB.
Auth0 does.
idsrv4 essentially adds features by code. Auth0 has config. via wizard.
idsrv4 is open source so you can customise to your heart's content. I find it really useful to bridge systems.
Azure AD is another option.
I'm a complete newbie on the concepts of web security and I was having a pre-conceived notion that securing the application is incredibly hard.
Looking at a video on Apache shiro, I have a feeling that the complexity of security has all been abstracted in form of a nice, simple, unified API.
I'm trying to write a security layer which will be responsible for Authorization and SSO for my underlying SOAP based webservices.
The permissions will all be sourced from LDAP (OpenDS) which will be maintained on my side (ie not external), as they reflect the bunch of functionality available on my system.
I have a requirement that clients can have their user management in Active Directory (external) and once they log-in to AD (probably their windows login), they should automatically be authenticated to be able to consume my services.
Then I will check whether the user has got the right authorization to consume a specific service.
This effectively means, Authentication is done externally but authorisation is done internally as far as my boundaries are concerned. But my security layer has to understand that the user has been authenticated and know who the user is.
Is this achievable in Shiro? Any pointers would be of great help.
How can I make my desktop application into an OpenID relying party?
Have a look at this question, it looks to me that OAuth can do this for you.
Since OpenID has a specified protocol, it will either work all the time (assuming providers are conforming) or not at all. Additionally, since the OpenID protocol (at least the authentication bits, see the specification) consists of simple HTTP requests, you could implement the protocol in a desktop application assuming you know how to make such requests.
It is generally considered a bad idea though, since there are better technologies (OAuth) and it disrupts the user experience (being different from OpenID in a browser — see OpenID For Desktop Applications: How? When?).
Further reading: OpenID for Desktop Clients
Don't do it.
Even an attempt to do so shows a fundamental lack of understanding in the security model that OpenID offers. You have to ask yourself what the password that you would otherwise use for your desktop app is protecting. Is it protecting assets on the local machine itself? If so, OpenID is useless because it would be a simple matter to spoof the network such that I could hack my way into the desktop app without owning the OpenID. You're wide open to user identify spoofing. Are you trying to protect network assets? OpenID fails again, since it doesn't authorize your desktop app to access those network assets, suggesting that some other authentication is going on behind OpenID so once again you're not adding any value.
OAuth is the protocol suited to allow your desktop app to access and protect network resources. If you're protecting local assets on the desktop computer, local encryption is the only way to go.
It seems to me that you should present a small web browser window for the authentication to be completed. The interaction would not be going through your code.
I would not suggest using web scrapers to do this. In doing so, you place your code in between the user's server and the user, which is a breach of the covenant that the user's password is not seen by the relying party.
OAuth is the right technology to use for a desktop application, but it doesn't use the existing password ecosystem that OpenID has, which was not a part of the OP's question.