I am using the Pubnub library (Pubnub-CodeNameOne-3.7.8.cn1lib) in my social app project (which includes a real-time chat that I implemented with your great tutorial: https://www.codenameone.com/blog/building-a-chat-app-with-codename-one-part-5.html).
But since Apple will no longer accept http URL connections from applications, I had to reinforce the security of my app, and so I decided to use HTTPS and activate the Access Manager feature in Pubnub dashboard (I followed the Pubnub tutorial https://www.pubnub.com/docs/codenameone-java/pam-security#understanding_access_manager_permissions_hierarchy).
So I changed the instantiation of Pubnub in my CN1 project like :
pb = new Pubnub(PUBNUB_PUB_KEY, PUBNUB_SUB_KEY, SECRET_KEY, true);//enable SSL
pb.setAuthKey(USER_UIID);
Unfortunately I still get an error when I subscribe/publish through Pubnub:
[Error 112-0] : Authentication Failure. Incorrect Authentication Key :
{"message":"Forbidden","payload":{"channels":["myChannelID"]},"error":true,"service":"Access
Manager","status":403}
Therefore, I would like to perform administrative PAM functions, such as granting or revoking, in order to solve the above error message problem.
But I don’t find the pubnub.pamGrant(), or pubnub.pamRevoke() methods which are mentioned in the Pubnub tutorial. So I am still stuck on this error.
Have you an idea about how I can resolve this? Thank you very much for your help.
PubNub Access Manager & SSL/TLS
While you should be using Access Manager to secure your channels on a per device/user basis, Access Manager is not required in order to use PubNub over TLS (SSL is the deprecated/vulnerable predecessor and often these terms are used interchangeably).
So your initialization code is correct to enable TLS (https connections) when PubNub operations are invoked.
pb = new Pubnub(PUBNUB_PUB_KEY, PUBNUB_SUB_KEY, SECRET_KEY, true);
But if you enable Access Manager on your key set (pub/sub keys), then you are required to grant permissions (read, write & manage) for channels on auth-keys. Each end user should have a unique auth-key that has the permissions for the channels that are required for that user to publish, subscribe, get history, presence, etc.
You grant permissions from your secure server which you initialize PubNub with the publish, subscribe and secret keys (secret key is required to execute the grant API). With v4 PubNub SDKs, the server has super admin permissions when it inits with the secret key. v3 SDKs require the server to grant itself access to its own auth-key but since Codename One is for mobile client apps, you don't need to wait for a v4 PubNub SDK for Codename One. And I would assume you would be using Java on your server and our v4 Java SDK v4 has the super admin permissions feature when initialized with the secret key. NOTE: the docs need to be updated as they still state that an auth-key is required even when secret key is used to init.
So my recommendation is, enable SSL (TLS) as you are already doing for your server and clients but disable Access Manager for the short term. Once you have your base functionality working, integrate the use of Access Manager and auth-keys into your server and clients.
Related
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?
How can i use MFP (8.0) adapter based authentication without installing mfp client sdk / libs.
Is it possible to make REST call to the adpater (login) directly from the client application (mobile) without the client sdk.
Updates:
I have tried confidential client option , but i need individual user details instead of pre-defined client id.
You can't make Adapter Based Authentication in your Client Application without MobileFirst SDK.
However this is possible only with unprotected adapter endpoint.
Security check adapters cannot be accessed via REST calls. You can protect your resources with scopes mapped to these securitychecks and they get invoked when the resources are accessed. At the client, uou handle the challenges that come from the securitychecks. This needs the MFP Client SDK to be in place. You cannot access the securitycheck adapters directly without MFP client SDK.
There are two ways for you to avoid invoking a securitycheck:
Do not mark the resource with any security. In this case default security scopes get applied. However you still need MFP client SDK to handle the OAuth handshakes.
The only other way to avoid invoking security check adapters is to explicitly mark your resources un-protected ( disable OAuth security for that resource). This will prevent any challenge answer mechanism and you can access the resource without MFP client SDK. Do note that your resources (via REST endpoints) will be open to attack - there will not be any security applied on it.
So I want to have single sign in, in all the products using a auth server but that's not only for employees, keycloak should be used to that like auth0?
There are also some advantages to Keycloak:
Keycloak is also available with support if you buy JBoss EAP (see http://www.keycloak.org/support.html). This might be cheaper than the enterprise version of Auth0. If you want to use custom DB, you need enterprise version of Auth0 anyway.
Keycloak has features which are not available in Auth0:
Fine-grained permissions and role-based access control (RBAC) and attribute-based access control (ABAC) configurable via web admin console or custom code or you can write yuour own Java and JavaScript policies. This can be also implemented in Auth0 via user rules (custom JavaScript) or Authorization plugin(no code, less possibilities). In Keycloak you can do more without code (there are more types of security policies available out of the box e.g. based on role, groups, current time, an origin of the request) and there is a good support for custom developed access control modules. Here some more detailed research would be interesting to compare them.
Keycloak also offers a policy enforcer component - which you can connect to from your backend and verify whether the access token is sufficient to access a given resource. It works best with Java Web servers, or you can just deploy an extra Java Server with Keycloak adapter which will work as a gatekeeper and decide which request go through and which are blocked. All this happens based on the rules which you can configure via Keycloak web interface. I am not sure such policy enforcer is included in Auth0. On top of that, Keycloak can tell your client application which permissions you need when you want to access a given resource so you do not need to code this in your client. The workflow can be:
Client application wants to access resource R.
Client application asks Keycloak policy enforcer which permission it needs to access resource R.
Kecloak policy enforcer tells the client application which permission P it needs.
The client application requests an access token with permission P from Keycloak.
The client makes a request to the resource server with the access token containing permission P attached.
Policy enforcer which guards the resource server can ask Keycloak whether permission P is enough to access resource R.
When Keycloak approves, the resource can be accessed.
Thus, more can be centralized and configured in Keycloak. With this workflow, your client and resource server can outsource more security logic and code to Keycloak. In Auth0 you probably need to implement steps 2,3,6 on your own.
Both Auth0 and Keycloak should be able to achieve your goal - assuming you want only social (facebook, google etc), and /or username & password authentication?
Auth0 is the less risky option, keycloak is good for non-commercial & where you can afford production outages without a global 24x7 support team. Here a few other reasons why I'd recommend Auth0 - the documentation is world class, they have quickstart samples so you can get up and running in minutes, and easy access to more advanced options - passwordless, authentication, MFA, anomaly detection, x9's reliability, rate-limiting, an extensive management api, extensions for everything eg exporting logs to log aggregator, and so on. Anyhow, good luck with your project, and obviously what suits best may simply be down to your own project requirements.
Should add, if you are doing mobile, then Auth0 put a lot of effort into adding the necessary specialised security flows to target mobile (native / hybrid) apps. For instance, PKCE usage when using /authorize endpoint. Please bear that in mind, as not certain how keycloak has been implemented to handle this - alot of IDMs still do this incorrectly today.
I have a website and an API. The website allows anonymous people to browse the catalogue, but you must be logged in to post stuff.
I have built an API that exposes the same functionality. The API is used by a mobile app we are developing, but we are also going to allow other developers to use the API (i.e. it's publicly documented). The entire API is currently requires OAuth (2.0) authentication. To prevent abuse we use rate-limiting per OAuth client-id/user-id combination.
Now a new requirement for the mobile app has come down: The app should allow anonymous users to browse our catalogue. I am not sure how to implement this, without opening up our API to abuse.
Anonymous OAuth access
The first problem is allowing anonymous access. If we still want the entire API protected by OAuth then our mobile app will have to use the client-credentials grant type (posting a client-id and secret key). But we would have to store the client-id and secret in the app itself. This is not secure since it can easily be reverse engineered.
Alternatively, we could use dynamic client registration. As soon as an app is installed, it registers with an (undocumented) API to create an OAuth client for itself. Problem here is, how do I protect the client registration endpoint? A secret key again? Plus, this leads to a large amount of OAuth clients registered.
Remove OAuth from public endpoints
Alternatively, we could remove OAuth from the public endpoints all together (i.e. browsing the catalogue) and only require OAuth for posting stuff or managing an account. But how would I protect the API from abuse then? Without OAuth I cannot rate-limit based on client-id.
I am not sure that rate-limiting based on IP address would work. We expect many mobile app users and I fear that crappy (Moroccan) mobile telecom providers are NAT-ing a large amount of phone users behind just a few IP addresses. This would quickly exhaust any rate-limit that we set.
Is this correct? Or can I safely rate-limit on IP address for mobile users?
Alternative security mechanism
I could also implement a different authentication mechanism alongside OAuth. Something that allows our mobile phone app access to the API, which can distinguish (and rate-limit) different phones/users but which is safe from people just extracting a shared secret key from our mobile app binary.
Any suggestions on how to allow anonymous access to my API but still rate-limit effectively?
Since, the mobile app is installed on a device, if you configure a secret, then that secret will be common for all installations of the mobile app. Thus, derailing the purpose of a secret.
You should do dynamic registration. Here are the steps
Developer preconfigures the the following information with a trusted authority.
{
"software_id":"COMMON_VALUE_HERE",
"software_version": "OPTIONAL_BUILD_VERSION",
"client_name":"HUMAN_READABLE_CLIENT_NAME",
"client_uri":"OPTIONAL_FOR_CLIENT_CREDENTIALS",
"logo_uri":"OPTIONAL_FOR_CLIENT_CREDENTIALS",
"tos_uri":"OPTIONAL_TERMS_OF_USE"
}
The trusted authority generates a "software_statement" in exchange of the information that the developer provided. This contains the information that is constant for all installations of the native app.
After the app is installed on the user device, the app contacts the Authorization server for dynamic registration. The app posts the following to Authorization server
{
"redirect_uri" : "OPTIONAL_FOR_CLIENT_CREDENTIALS",
"scope": "SPACE SEPARATED SCOPES",
"software_statement": "MANDATORY"
}
The Authorization server verifies the information present in the "software_statement", generates and returns back a "client_id" and "client_secret" that are specific to the particular installation of software.
The client calls "POST" method on token endpoint with the newly received "client_id" and "client_secret", and receives an "access_token".
The client uses the "access_token" for accessing the "protected_resource".
The source of my answer is "oauth 2 in action" by Manning publication.
Worklight 6.1 documentation identifies that "credentials" such as password can be added to the user identity object (UIO) provided to WL.Server.setActiveUser().
How & where is the UIO stored on the WL server, and is this considered a secure storage?
Trying to understand the security implications of storing password in this structure to be retrieved and used for subsequent back-end access (Cloud) requests. If not secure, can encryption be applied to the any part of the UIO?
Appreciate any advice you can provide.
The User Identity object is kept in memory and is scoped to the current session.
In other words, the credentials are not persisted; one would need to dump the server memory and dig through it or connect with a debugger. It's considered secure. The production server is also supposed to run in a secure environment with limited access to the process, etc... of course.
The credentials stored in this object can be used by the adapter to authenticate with a back-end on behalf of the user.
In a HTTP adapter, the authentication schemes Basic, Digest and NTLM use that technique
In non-HTTP adapter and in custom authentication schemes, the developer can use those credentials as necessary.