I have two questions :
1- Does the MobileFirst ver 7.1.0 provides encrypt functionality on the client side and decryption on the server side?
2- I need to pass username/pswd to the database through an adapter call. From client when I call adapter and pass these credentials it goes as a query string. How can I hide these while send it to server-side adapter?
Does every mobile user have his/her own username password for the database? If so this is not ideal design. The database credentials must be held in the adapter's xml and the user must be authenticated to MobileFirst using security tests and login & authentication modules.
If you still go by your original design, you can use Java adapters to accept credentials from the user through the payload of the call rather than query parameters. See https://www.ibm.com/support/knowledgecenter/SSHS8R_7.1.0/com.ibm.worklight.dev.doc/devref/t_impl_java_adapter_JAXRS.html
Having done this, make all your calls over HTTPS for the traffic to be encrypted during transit.
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?
I am developing two linux programs, a CLI client and a server communicating via gRPC, and I now would like to authenticate users against a given private authorization server such as LDAP, Active Directory, etc.
I am confused regarding the various possible authentication flows. I think I can't use any classical flow including HTTP redirects since I shouldn't rely on a browser being installed or having internet access. I can't even define an endpoint I could redirect to (servers don't have internet access, and both are behind NATs).
So I was thinking of trying to store user's credentials as a JWT token file in the user's computer and then load it from my CLI client program to include it in my RPC requests and then validate it on the server-side. But, supposing I'm right, then what would be the best standard way of getting this token file?
If you had a browser you could use OAuth and the 'oob' (out of band) method where the CLI opens the browser and after the user authenticates it displays a number which the user copy/pastes into the CLI. This how my flickr backup CLI works. The number they copy/paste is because the CLI has no OAuth endpoint and the number is their access token to allow me to call the flickr api on their behalf.
If you can't use a browser the CLI can just accept a username/password from the user, send it to the server and receive a token in return. You don't really need anything fancy like JWT. A simple UUID would be enough. The UUID 'asserts' that the user is allowed to access the server's other RPC methods. The server would validate the UUID token to make sure it's still valid. If you need user information from the token, the server could do that. Keeps the user information off the client's disk and only the CLI can access that information, if the token is still valid.
So in effect, you need a new server RPC method, perhaps, authenticate, that accepts a username and password and returns a UUID token. All other RPC methods then need to accept that token and validate it before performing the requested function. As part of the server-side authentication process, the server could associate that token with the user information it got from the LDAP server so you don't need to store that information on the client. Lets you encrypt it on the server too and if the client needs it, it asks for it using the UUID token if it's still valid (time to live?). If it's no longer valid, the client just needs to ask for username/password again and the server can re-authenticate the user via LDAP and refresh the token and user information.
gRPC has authentication protocols but the SSL/TLS doesn't seem to match your needs and the OAuth won't work as you don't have a browser. So perhaps rolling your own simple token service (authenticate) combined with LDAP authentication might be a workable option.
We are developing an inhouse application, which will be distrubuted via Mobileiron. I can get the active-directory/mobileiron user name and device id from mobile iron. What i need to know is, when a web service call comes to my api, i want to make sure the call is coming from a client who is logged in to my app using mobile iron. I have no idea how to do this. My manager doesn't want to use Kerberos for single sign-on and all the documents i could find contains messy information.
Can someone please show me the way in some detail? do i need to use certificate or Sentry? How should i do that?
I am running out of time so any help would be appreciated.
From my experience, you do not need to use Kerberos. You can use certificate-based authentication and have Mobile Iron configured to return the certificate. If you are using AppConnect API you can have the base-64 encoded cert (.p12) and password provided as part of the configuration object (via AppConnect.sharedInstance().config), which would then be passed along to the server for authentication. The LDAP user's email is embedded in the cert, so the server can associate it to a user.
There's also the option of using "pass-through" authentication which basically trusts the client is authorized. Not the safest option.
Let's say I have a system that's currently like this:
Monolithic Web App: Contains its own accounts and relies upon clients to log-in with (essentially) HTTP BasicAuth. That is, the username & password are getting passed to the server.
Thick Client: Logs-in to the above app, receives access token it uses thereafter for REST API calls.
Basically, I'd like to transform the above into this sort of system:
SAML 2.0 IdP: System of record for identities
Same Web App, minus Authentication responsibility
Thick Client: Unchanged. <-- hard requirement
So, crucially, I can't have the thick client do the standard SAML 2.0 Browser SSO redirects. Is there any solution? Essentially, I'd like the same functionality as OAuth2's password_grant, but in the SAML 2.0 world.
Doing some research, I've come across the SAML Enhanced Client or Proxy, but support seems spotty. The frustrating thing is, I have the darn credential in cleartext at the WebApp; is there some simple way to make this work?
Would the HTTP Artifact Binding do the trick?
NOTE: This question should perhaps better be asked on https://security.stackexchange.com/.
If you cannot change the thick client, then you cannot use SAML, or any form of browser-based single sign-on (SSO). It's as simple as that.
Also, your approach of expecting users to type their SSO credentials into the thick client, and then sending them through HTTP basic auth and automatically typing them into a form is insecure for several reasons:
The user's plain text password needs to be passed through several instances that should never see it, and it will probably also be stored in the thick client. Even if it is encrypted (in transit or at rest), this is less secure than the password being only stored as a hash on the IdP (and in the memory or password manager of the user).
Expecting users to enter their SSO credentials anywhere else than the login form of the IdP promotes dangerous use of credentials which can make users more susceptible to phishing.
If you are planning to use the IdP for SSO to more than one client than this one legacy thick client, you can use something like application passwords:
The user logs in to a web app using SSO (SAML)
The user creates an application password (and also has the option to revoke it)
The application password is then used with the thick client.
The "application password" can be a combination of a simple unique ID (which is entered as the "username") and a long random-generated string (which is sent as the "password"). If the thick client can store these credentials, then this approach would be somewhat user-friendly, although not as secure as true SSO.
In the long run, do consider updating the thick client.
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.