I have gone through IBM Worklight Authentication concepts. Now I have few questions.
1) Is there a practical use of Formbased authenticater ?
All the examples I have seen uses NonValidating Login module which doesn't really validates the credentials. So what if I want to use the Form based authenticator to check the credentials against the db ? Can you please point me to a real world example ?
2) If I choose custom security test for my application, I won't be get the wl_antiXSRFRealm enabled by default, what if I don't use it, is my app vulnerable to attacks ?
3) Read in one of the article "Therefore in case your security configuration is close to default security settings you might want to use webSecurityTest and mobileSecurityTest. "
It means, we are not going to ask the users to enter credentials ?
4) A practical scenario where Custom Login module & Custom Authenticator can be used ?
There is no connection between either Form-based authentication or adapter-based authentication and the non-validating login module. You could implement them by using non-validating, or by actually validating the user credentials...
Non-validating login module is used in the sample because we cannot supply you a back-end with the sample; the purpose of the sample is to show the implementation of the client-side.
In form-based, the form is returned by the server. In adapter-based and custom-based you are less restricted and can handle this in the client. Either way, you handle the authentication using a challenge handler.
Also, please read: Understanding predefined Worklight authentication realms and security tests.
If you use a custom security test, there is no such thing as "default". You determine which tests will be in it. Simply add it back.
The antiXSRFRealm has got nothing to do with user credentials and your login module.
It is mainly used for Desktop websites and not for mobile devices; if you want, add it back in your custom security test.
Related
I'm using keycloak to let my users authenticate with my application. And i am trying to migrate some functionality to a few plugins, e.g. a wordpress plugin. For these plugins i want to use a generic solution so I found the following authentication process from Microsoft (https://learn.microsoft.com/en-us/office/dev/add-ins/develop/auth-external-add-ins#middleman-services) and Adobe ( https://adobexdplatform.com/plugin-docs/tutorials/how-to-integrate-with-OAuth/).
I managed to hack my way around the process to get this working with keycloak. But at this moment I'm a bit concerned about the security risk that go with this process.
The process in steps
the (plugin) client asks to backend server to generate a code to identify the user.
the (plugin) client start polling the backend for an authentication code (no response yet, since the user is not logged in yet).
the plugin opens a browser window or tab with the keycloak loginpage. Everything is the same as the normal process, but this time we add an redirect uri with the code generated in step one, which identifies the user.
once the user is logged in the user gets redirected in the browser to an endpoint where the code from step one is linked to the access token retrieved in this step.
the polling from step 2 now returns the access token to the (plugin) client.
The reason I need to poll for the access token is because I want to make a generic login process for all client.
In short, I want to know what the security risks are, given the steps above. Also I can not seem to find any information of keycloak that they want to implement such feature. Does anyone know if they want to implement this, since many other plugins do offer tis feature to authenticate outside the plugin with a popup window and retrieving the accesstoken by "polling" the server.
Thanks for the help.
I am implementing login within a new native application (iOS and Android) and deciding on the kind of authentication to adopt. There are some quite clear guidelines around OAuth that state that this should be done using an external agent (browser) and this leads me to Authorization Code Grant with PKCE
https://www.rfc-editor.org/rfc/rfc8252
Implementation here: https://appauth.io/
However, my designers and product owners are sceptical. They dont see that kind of login very much (they dont like the address bar) and want to explore the Resource Owner Password Credentials option. Essentially direct login. Their argument is that it is simple and familiar.
I dont want to compromise security and as such I am resisting this option. But... I have read some articles that seem to suggest that this could be secure if I dynamically generate the client used for the auth request:
https://www.rfc-editor.org/rfc/rfc6749#section-10.1
The authorization server MUST NOT issue client passwords or other
client credentials to native application or user-agent-based
application clients for the purpose of client authentication. The
authorization server MAY issue a client password or other credentials
for a specific installation of a native application client on a
specific device.
This is backed up by AppAuth documentation here:
https://github.com/openid/AppAuth-Android#dynamic-client-registration
https://www.rfc-editor.org/rfc/rfc7591
Am I interpreting this correctly? I am considering initial user registration in-app that returns an access token that can be used to dynamically generate a client (with secret) that can be used for login using ROPC.
I am thinking to be secure then this dynamically generated client should only be used for login for the single user - one client per user, but maybe one client per device is also secure enough.
It seems a little 'hand rolled', so I am nervous. Am I right to be so?
We have an auth infrastructure based on OAuth2 that is integrated into a variety of web apps within our organization. We also have a pure native application with no middle-ware of its own, and we want to integrate authentication into this native application. This application already has its own internal login mechanism with a native login screen, and we don't want to have it start launching external components like web browsers in order to display login windows. We are both the app provider and the auth provider, so the concern of the app having visibility into the user's credentials is less of an issue -- we trust ourselves to not intentionally do anything untoward with the user's credentials, and it's the same people writing a login form in the app as writing it on a web site. :-)
We are trying to figure out how best to support having the application continue to collect credentials the way it does now, but use them to obtain an auth token within our auth framework. With the APIs in place right now, the only way I can see for it to be done is to bake a Client Secret into the native app so that it can use a Resource Owner Password Credentials Grant request, since the code that would normally be making this call doesn't have a server side to live in. This feels really wrong, somehow. :-P
As far as I can see it, many of the structures of OAuth don't really apply to this app because it's not living in the context of a web browser, it doesn't have any concept of a "domain" nor any sort of "cross-domain" restrictions. It has been suggested that perhaps we create middleware for this app just for the purpose of exchanging authentication codes for tokens, but the rationale for that seems to be that this middleware theoretically ought to be able to somehow vet requests to determine whether they are legitimately from the application, and I don't see any way to do that that couldn't be faked by anyone with access to the client application code. Basically, the only purpose such middleware would serve would be to make the Client Secret irrelevant with respect to getting auth codes for credentials.
One thought that came to us was, how does something like Windows do it? Windows very obviously uses a native login form, but then some flow exists whereby the credentials that are entered are used for authentication and presumably, deep in the internals of the OS, for obtaining an auth token. Does anybody know if this architecture is documented anywhere? Does Microsoft's architectural choices here have any relation to OAuth2? What is the "best practice" for an application if you take it as a given that it doesn't have middleware and has its own native login form?
FWIW you don't need a client secret to use ROPC Grant to obtain or refresh tokens if the client is configured as a public client, i.e. a client that isn't capable of storing a secret.
RFC8252 OAuth 2.0 for Native Apps encourages using a native user agent for your scenario, using authorization code flows with PKCE. Authorization services like Okta and Auth0 have jumped onboard too, although they still recommend ROPC if the client is "absolutely trusted".
RFC6819 OAuth 2.0 Security discourages ROPC, but also says "Limit use of resource owner password credential grants to scenarios where the client application and the authorizing service are from the same organization", which are first-party apps.
So while the security verdict seems to be that authorization code+PKCE is the best practice, the UX hurdle of showing a user a browser window to log into a native app seem to be keeping ROPC alive. It's difficult to tell if that UX is jarring because people aren't used to it or because people can't get used to it.
So i'm tasked with implementing SSO for our Windows application. Currently, after a user logs into the machine, he or she has to re-log in to our app when he or she loads the application. The application validates the user by querying a LDAP server.
What we're looking to have is for the user to automatically be logged into the app when they click on it. My understanding is that the LDAP authentication must still happen, but Im not exactly sure what the workflow would be, and how exactly we can validate a user without requiring them to re-enter a username / password. Note that this is not a web application so I can't use tools like SAML or OAuth (unless i'm mistaken about this too..?)
So my specific question is as follows:
Is it possible to use LDAP for SSO, and if so, how? Is it possible for me to authenticate a user with just his or her username, or is a password also required?
Any guidance would be appreciated, and am happy to provide further clarification if needed.
First of all, LDAP is a protocol, which you use to communicate with databases that implement this protocol.
So LDAP databases (commonly called directories) are ... databases and so do not provide SSO functionality.
To deploy a SSO solution, you need a SSO service. All your applications will have to be "compliant" with this service in a way or another.
The only way I can think of to make a "Windows SSO" without adding a third party application is that the applications can retrieve NTLM informations in requests made by the client and uses the user data to identify him. (but in term of security, I let you judge what you think about it ;) ) . See this php example
Some LDAP implementations, including OpenLDAP, provide some level of support the Generic Security Service Application Program Interface (GSSAPI) or SPNEGO (a specific GSSAPI implementation)
Although not trivial, it is possible to perform SSO from a "browser" that supports GSSAPI. AFIK, IE, Firefox, Safari and Chrome all provide some level of support for GSSAPI although each browser requires specific configuration (typically whitelisting of Servers).
There are many SSO Products that implement these features in a "probably" more secure and easier process than doing it yourself.
There are many known vulnerabilities details that have been exploited with GSAPPI/SPNEGO typically due to implementation issues.
We are working implementing Single Sign On(SSO) using pingfederate. The basic implementation uses a login token sent via browser cookies for checking user authentication. What's the recommended way of doing the authentication check? Should I use a login filter or configure form-based authentication?
Both can be done as good. The difference is only that you've to write all the code yourself in one case and just do some (XML) configuration according existing guidelines in the other case.
Either way, I think the benefits and caveats are obvious enough. In this particular case, I'd go for container managed authentication to avoid future maintenance headaches.