I am new to Spotfire. I am trying to implement two factor authentication for Spotfire Web player login. The instructions provided on Spotfire support portal is not specific. Can anybody help me on this?
Well, the only form of two-factor authentication that is supported out-of-the-box would be the combination of some standard authentication method (such as plain username/password) with X.509 client certificates (which could be stored on smart cards or such).
Another option could be to utilize some external authentication provider (typically using OpenID Connect) and configure two-factor authentication there.
Related
I am currently looking for a method to provide site wide authentication, for services exposed to the cloud, on the site I am responsible for. Some services are a Python based, some in PHP and some in Perl. Individual services would need to be able to get access to the user profile and the associated roles.
On the main page users are logged in and a cookie is created using a JWT token. The main site is using NodeJS for the auth system and is built in-house.
At this point I am wondering whether we should use OAuth2 across the site or whether there is another approach that may be simpler, where we don’t need to deal with inter domain requirements?
The approach you're currently investigating is the re-use of a JWT as an authentication token across multiple services. Although it's technically possible - it is not the ideal secure approach.
The most secure approach is for separation of application contexts, whereby each application should be tied to a different application credential (in OAuth2 terms). This is ensures that the user receives a credential unique to that application, allows the credentials to be managed/revoked separately and audited in isolation.
To implement this smoothly for UI flows requires an identity provider that supports SSO, and also assumes that each UI application can handle negotiation to the IDP to access that SSO session.
For interactions that are system to system authenticated, eg. Python, you would need to use system to system authentication (OAuth2 client credentials) that again have its own credential. In the case where you need access to the end-user's profile, a management api key (or similar) would be required.
I have a scenario where I have to let external systems have access to one of our internal API's.
The security team want the externals to use client certificates as the preferred authentication method, so that basically leaves us two options:
Use direct client certificate authentication. It will give us the most control, but that will leave all the certificate handling and validation in our hands, and I'd rather not do that if I have a choice. Besides - direct client certification auth does not play well with our existing authentication methods on that API. If you turn on client certificates on the App Service, you will require a certificate on every request (and most requests on that API use cookies)
Add key credentials to the Azure AD app. We'd rather not give access directly to the app the API is registered on, so we register a OUR-APP-EXTERNAL and set up a trust relationship between the two. So the client authenticates with a certificate to the "external app", gets a bearer token and use that on our API. I'd prefer to use this solution, and it seems to play nicely with everything else.
So far so good - but I'm worrying about scaling this. We have to separate the external clients somehow (each client will in effect be different systems in different companies). One strategy is to create one AD-app per external system (OUR-APP-EXTERNAL-SYSTEM-A), but it seems cumbersome and somewhat spammy. One quick and easy solution would be to add some metadata from the client's authentication certificate (where we could just set what system this cert is issued to during creation), and add that to the bearer token.
Is this possible? Or are there other ways to handle "multi tenant" external clients?
Thanks
Consider an option of using Azure API Management for your scenario. API Management provides the capability to secure access to APIs (i.e., client to API Management) using client certificates. Currently, you can check the thumbprint of a client certificate against a desired value. You can also check the thumbprint against existing certificates uploaded to API Management.
Follow this guide - How to secure APIs using client certificate authentication in API Management
Also you can create multiple Azure AD Application for different clients and provide provide required roles to each of these Azure AD application to Azure AD Application registered to secure Internal API.
Follow this guide for this approach - Protect an API by using OAuth 2.0 with Azure Active Directory and API Management
As I understand it, if you want your app to sign in via OAuth then you have to write separate code for each provider (Google, Twitter, etc).
And with OpenID you don't - it handles the providers for you and you just handle connecting to OpenID.
Now that OpenID has become OpenID Connect (which is a layer running on top of OAuth 2.0) if I use it would I still need to write separate code (since it relies on OAuth), or would I just need to write a single bit of code for the OpenID part and it would handle all the underlying OAuth providers?
Conceptually, OpenID is a SSO (authentication) protocol while OAuth is an authorization (access resource on behalf of the user) protocol. Practically, both seem close as the user needs to login. OAuth supports several different flows and OpenID is built on auto-discovery (the user identifier references the identity provider). OpenID Connect is built on top on OAuth with the auto-discovery idea of OpenID (specific url).
For these three protocols, you don't really need to write separate different code for each provider, you can have some common component with customizations due to the different configuration (server url) or attributes retrieval configuration. For OAuth where things are a little blurry, implementations may have more substantial differences.
Taken from my experience of the pac4j security library: https://github.com/pac4j/pac4j
we have openAM set up with two-factor authentication using one time SMS code which worked fine up till now. Unfortunately the requirements from the client's side have changed and we would like to be able to disable/enable two-factor authentication (SMS/no-SMS) at runtime by parameter set/unset in another system (through openAM API).
Is there a way to do this ?
OpenAM offers Service Management API (which is also used by 'ssoadm') which you can use to change authentication chain etc. Not sure if this is what you are looking for.
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.