I'm developing an application with Grails.
Im trying to implement an SSO-functionality. But I can't authenticate the users via windows session, because some of them has another windows passwort as the domain password.
(I retrieve the users via LDAP) So, how can I authenticate them?
Scenario should be following:
User goes to the Grails-Site
Popup appears where the users has to fill in with his credentials
After that, he has never to authenticate again...
Does anyone of you has some experience with it?
I think if you need SSO for many grails applications a good choice is to add saml support to your grails applications using this plugin and then build an IdP (there are many in many languages) and connect the IdP to your ldap.
SAML is standard and is the future.
If you need more info about saml check the saml entry at wikipedia. There you can find links to documentation and software.
Related
I am Using Sharepoint2019 On-Premise
I am looking to use separate .aspx page for authenticate users for Sharepoint2019,
I tried the Form-Based Authentication(https://learn.microsoft.com/en-us/previous-versions/office/sharepoint-server-2010/ee806890(v=office.14)) and it works for authentication but the user profiles are not getting synced from our current Active Directory, so i would like the go back to the windows authentication but instead of pop-up should i would like the .aspx
I want to Use this page for Windows Authentication :-
I Do Not Want This SIgn in pop-up
can any one please guide me to accomplish this task.
One suggestion to look at would be to use AD FS and Web Application Proxy. This solution would require you to configure Kerberos Constrained Delegation for the SharePoint Web Application. In addition, the WAP server(s) need to be joined to Active Directory. Finally, on AD FS you would set up a non-claims aware relying party.
DNS for your Web Application would be pointed at the WAP server (or load balancer routing to WAP) and users would log in there using an FBA experience but still using Windows auth on the back end.
You need an external system that can pass non-Windows auth and translate it to Windows auth. AD FS + WAP is one example of doing so. Because the back end is still Windows auth, other services that leverage Windows auth will continue to work without any changes to your farm.
See here :- https://learn.microsoft.com/en-us/answers/questions/153678/how-to-use-custom-login-page-aspx-as-link-fba-for.html
See https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-non-claims-aware-relying-party-trust on how to create a non-claims aware relying party.
For TLS setup, see https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn383662(v=ws.11).
it is quite tricky, as Microsoft Designed in that for the windows authentication, but any how if you can use the Form Base Authentication.
Here is the Link where Microsoft posted how to implement the Form Based Authentication.
Configure forms-based authentication for a claims-based Web application
I have an OpenID Connect provider built with IdentityServer4 and ASP.NET Identity, running on let's say: login.example.com.
I have a SPA application running on let's say spa.example.com, that already uses my OpenID Connect provider to authenticate users through login.example.com and authorize them to access the SPA.
I have a mobile app (native on both platforms) that is using a custom authentication system at the moment.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
So I started by looking on the OpenID connect website and also re-reading the RFC6749, after a few google searches I realized that was a common problem and I found RFC8252 (OAuth2 for Native clients), also Client Dynamic Registration (RFC7591) and PKCE (RFC7636).
I scratched my head about the fact that it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised.
I disscussed the topic with some co-workers and we came out with the following set-up:
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Use an AuthenticationCode flow for both clients and enforce them to use PKCE.
Use a redirect_uri on the app associated domain say: https://app.example.com/openid
Make the user always consent to log-in into the application after log-in, because neither iOS or Android would bring back the application by doing an automatic redirect, it has to be the user who manually clicks the universal/app link every time.
I used AppAuth library on both apps and everything is working just fine right now on test, but I'm wondering:
Do you think this is a secure way to prevent that anyone with the right skills could impersonate my apps or by any other means get unauthorized access to my APIs? What is the current best practice on achieving this?
Is there any way to avoid having the user to always "consent" (having them to actually tap the universal/app link).
I also noted that Facebook uses their application as a kind of authorization server itself, so when I tap "sing-in with facebook" on an application I get to a facebook page that asks me if I would like to" launch the application to perform log-in". I would like to know how can I achieve something like this, to allow my users login to the SPA on a phone by using my application if installed, as facebook does with theirs.
I thought it would be nice to get rid of the custom auth system, and instead allow my users to log-in with the same account they use on the SPA, by using my OpenID provider.
This is what OAuth 2.0 and OpenID Connect provides you. The ability to use single user identity among different services. So this is the correct approach .!
it was no longer possible to store any kind of "secret" on the client/third-party (the native apps) as it could become compromised
Correct. From OAuth 2.0 specification perspective, these are called public clients. They are not recommended to have client secrets associated to them. Instead, authorization code, application ID and Redirect URL is used to validate token request in identity provider. This makes authorization code a valuable secret.!
Associate a domain let's say app.example.com to my mobile app by using Apple Universal Links and Android App Links.
Not a mobile expert. But yes, custom URL domains are the way to handle redirect for OAuth and OpenID Connect.
Also usage of PKCE is the correct approach. Hence redirect occur in the browser (user agent) there can be malicious parties which can obtain the authorization code. PKCE avoid this by introducing a secret that will not get exposed to user agent (browser). Secret is only used in token request (direct HTTP communication) thus is secure.
Q1
Using authorization code flow with PKCE is a standard best practice recommended by OAuth specifications. This is valid for OpenID Connect as well (hence it's built on OAuth 2.0)
One thing to note is that, if you believe PKCE secret can be exploited, then it literally means device is compromised. Think about extracting secret from OS memory. that means system is compromised (virus/ keylogger or what ever we call them). In such case end user and your application has more things to be worried about.
Also, I believe this is for a business application. If that's the case your clients will definitely have security best practice guide for their devices. For example installation of virus guards and restrictions of application installation. To prevent attacks mentioned above, we will have to rely on such security establishments. OAuth 2.0 alone is not secure .! Thats's why there are best practice guides(RFC68129) and policies.
Q2
Not clear on this. Consent page is presented from Identity Provider. So it will be a configuration of that system.
Q3
Well, Identity Provider can maintain a SSO session in the browser. Login page is present on that browser. So most of the time, if app uses the same browser, users should be able to use SPA without a login.
The threat here comes from someone actually installing a malicious app on their device that could indeed impersonate your app. PKCE prevents another app from intercepting legitimate sign in requests initiated from your app so the standard approach is about as safe as you can make it. Forcing the user to sign in/consent every time should help a bit to make them take note of what is going on.
From a UX PoV I think it makes a lot of sense to minimize the occasions when the browser-based sign in flow is used. I'd leverage the security features of the platform (e.g. secure enclave on iOS) and keep a refresh token in there once the user has signed in interactively and then they can sign in using their PIN, finger print or face etc.
we would like to develop a new node.js based application using some SSO technology.
More applications will join then after using the same SSO infrastructure and logic.
We do not have specific requirements on the SSO itself, but it need to authenticate users
via a local DB (managing user name and passwords)
via our enterprise AD
via some external/federated SSO (I guess via SAML or so)
Also if it would support XACML it would be great.
I believe one of the most complete solutions on the market is the WSO2 Identity Server... but we would be open for others too.
The main question though is simply:
Is it possible to have such a solution in node.js?
Or do we need to shield node.js behind some (Apache) server to get SSO?
What would be the best approach?
Any inputs would be appreciated.
I've used azure active directory in my node.js projects for authentication, this might work as you are using active directory. Here is a sample.
I am completely new to ADFS. I need to access the ADFS server through node.js. I am searching for good reference notes, with implementation. And suggest me which protocol is best for requesting. Video tutorials are also heplful.
I assume what you want is to authenticate users in AD (via ADFS), for your nodejs based web app. I'd recommend looking first at passport.js.
ADFS supports 2 protocols for web sites: WS-Federation or SAML-P. WS-Fed might be simpler. We open sourced the strategy for WS-Fed and SAML that we use in our product. A strategy is essentially a plug-in for passport.
That strategy should give you a good start.
ADFS v3.0 exposes OAuth2. *
You could use Passport.js with OAuth support or Kong with OAuth support.
You could go the ADFS 2016 OpenId Connect route for ease of implementation (passport.js, only a feature request for kong).
If you're going the Azure route, there's one (passport-azure-ad by the Windows Azure team) specifically for that.
It includes OpenID Connect, WS-Federation, and SAML-P authentication and authorization.
Otherwise, versions disallowing etc., I recommend Eugenio Pace's answer.
Then, check these, is a complete solution (not a video tut)
Using Active Directory Federation Services to Authenticate / Authorize Node.js Apps in Windows Azure
http://seroter.wordpress.com/2013/04/22/using-active-directory-federation-services-to-authenticate-authorize-node-js-apps-in-windows-azure/
pretty fresh tut. (2013/04/22)
So I've read numerous articles on a password system for a web app, and they all seem very confusing. Some say you need to hash your PW's AND establish an https secure connection, others say you just need to hash AND salt your PW's.
I just know, after this has been done millions of times, there's PROBABLY some sort of library out there that can do a bunch of things for me for a password inputted on a client side, and give me something to save securely in my SQL Server 2008 database.
Do I need to worry about all the https secure connection stuff? Can I just make sure I hash the PW correctly? To hash it, do I need any external libraries or can I create a secure user/pw system entirely in .NET?
I've never done this before so any articles, tips, links would be very helpful. Thanks.
If you don't want to roll your own you can always use ASP.Net Membership
ASP.NET membership gives you a built-in way to validate and store user credentials. ASP.NET membership therefore helps you manage user authentication in your Web sites. You can use ASP.NET membership with ASP.NET forms authentication by using with the ASP.NET login controls to create a complete system for authenticating users.
ASP.NET membership supports facilities for:
Creating new users and passwords.
Storing membership information (user names, passwords, and supporting data) in Microsoft SQL Server, Active Directory, or an alternative data store.
Authenticating users who visit your site. You can authenticate users programmatically, or you can use the ASP.NET login controls to create a complete authentication system that requires little or no code.
Managing passwords, which includes creating, changing, and resetting them . Depending on membership options you choose, the membership system can also provide an automated password-reset system that takes a user-supplied question and response.
Exposing a unique identification for authenticated users that you can use in your own applications and that also integrates with the ASP.NET personalization and role-management (authorization) systems.
Specifying a custom membership provider, which allows you to substitute your own code to manage membership and maintain membership data in a custom data store
Configuring an ASP.NET Application to Use Membership
There's also a project on github called Membership Starter Kit for MVC
The default MVC3 Internet Application template (file-new project) has this setup for you already, simply add [Authorize()] to the controllers/methods you want to protect. Don't roll something new, use what's there for you. In addition, please use SSL as someone can easily steal a session by sniffing traffic and simply using your cookie. It's that easy.