I have a blockchain network built using Hyperledger Composer, started the Composer Rest Server and generated Java client code from the Open API spec to consume the REST Api. I have looked at the documentation to enable authentication and multi user mode. I already have authentication in my web application. How would I go about granting access to the user to interact with the blockchain after they sign into my web app?
Thanks.
Can you please tell us what strategy are you using for your web-application authentication?
Recently updated documentation # https://hyperledger.github.io/composer/latest/integrating/enabling-rest-authentication
The REST server uses the open source Passport authentication middleware.
Administrators of the REST server must select Passport strategies to
authenticate clients. Multiple Passport strategies can be selected, allowing
clients of the REST server to select a preferred authentication mechanism.
Passport includes a wide range of strategies (300+ at the time of writing),
including a mix of social media (Google, Facebook, Twitter) and enterprise
(SAML, LDAP) strategies.
You need to configure an appropriate passport-strategy to generate the access_token that will be used by REST API SERVER.
Related
I'm building a microservice based REST API and a native SPA Web Frontend for an application.
The API should be protected using OAuth2.0 to allow for other clients in the future. It should use the Authorization Code Flow ideally with Proof Key for Code Exchange (PKCE)
As I understand it I need to run my own OAuth Auth Server that's managing the API Clients and generating access tokens, etc.
Also I need my own Authentication/IAM service with it's own fronted for user login and client authorization granting. This service is the place the users login credentials are ultimately checked against a backend. That last part should be flexible and the backend might be an LDAP server in some private cloud deployment.
These components (Auth Server and IAM servicve) are outside of the OAuth scope but appear, correct me if I'm wrong, to be required if I'm running my own API for my own users.
However creating these services myself appears to be more work than I appreciate besides the obvious security risks involved.
I read about auth0 and okta but I'm not sure if they are suited for my use case with the application potentially deployed in private cloud.
I also thought about running Hydra (OAuth Server) and Kratos (IAM) by ory but I'm not sure if this is adding too many dependencys to my project.
Isn't there an easy way to secure an API with OAuth that deals with the Auth Server and the IAM that's good for small projects?!
We are developing a product that consists of a set of micro services developed as Spring Rest API, those APIs will be called using Angular JS client (not confidential client to server communication) and will also interact with each other (server-to-server communication );
We are in the stage of developing an SSO solution where we also want to implement authorization based on user roles for each API, while diving more through Spring Security, I have noticed the great support for OAuth2 standard, but at the same time I saw
Implementation for a CAS server integrated with spring client;
Now my question, why would someone goes with CAS server instead of using native spring security implementation and how roles will be passed from the CAS server?
You need to further study the concept of centralized single sign-on and different components in the architecture. Spring Security is a client library mostly used by the app to contact a server of some sort. CAS, as a software system, is a server. Your client application can use any library you like to contact the "account source" or the "identity provider" server. The server on the other hand, depending on the capabilities of the client will respond and react according to the semantics of the authentication protocol used.
Roles or more accurately put, attributes and claims are passed to the client app once tokens/tickets are validated using the CAS protocol. Other protocols more or less provide the same concept.
We are using WS02 ESB to create cloud app connections to our platform.
Our current issue: If we want to connect to any app (take salesforce as an example), we need the following details:
UserName
Password
Token
As a pre-requisite, the salesforce account should be API enabled.
We thought of using SSO in backend to avoid (3) and (4), but it's not possible with SAML(SSO).We are looking into ways to connect and publish data to salesforce with just Username(1)/Password(2). In this process of evaluation, SSO is one of the options
Any suggestions on how we can get the below details for APPS would be much appreciated!
• How do we get Token
• How we accept only the accounts where API's are enabled.
As far as I understand what you need is to call an SAML SSO secured backend app (i.e :- salesforce)?. If its the case you may use WSO2 Identity server for this purpose.You can obtain tokens from it.Further You can use this guide and this to call SAML secured backends through ESB.
Hope this helps.
You can use ESB Connectors to connect with Salesforce API. You can find Salesforce SOAP connector (which uses the username, password, and security token for authentication), Salesforce REST connector (which uses OAuth protocol) and Salesforce bulk connector (which also uses OAuth protocol) at WSO2 Store.
In WSO2 we have 150+ ESB connectors to communicate with third party API's via ESB. You can download the connector from WSO2 Store and can follow the documentation here. In connectors we have the mechanism to connect the third party API's(For Example In salesforce SOAP based connector we had the username password flow and for Salesforce REST connector we had oAuth 2.0 flow and the username password flow). In all connectors you just call the init method to get the Token to access the API.
We are implementing RESTful service and the entire backend application using Vert.x. These API's are consumed by a hybrid mobile app (developed using Ionic / angularjs). We are using Keycloak for user management and also authentication and authorization on the app.
My question is, how can I use Keycloak to also protect (authenticate and authorize for the same set of users) my RESTful service access which is implemented using Vert.x. Any example implementation would be very useful.
We wrote a custom Vert.x auth provider using the Keycloak core library to solve this exact problem (the Vert.x JWT library doesn't work with the Keycloak JWT tokens - arguably we should have improved the Vert.x library instead). I'll see if I can get permission to open source the library.
So, if i understand correctly, you need one authentication entry point for user in mobile app and in REST service. If i am right, you can use JWT. When user will authenticate with Keycloak he will receive jwt with roles and user information. This token you can put into request for REST service and your Service will know who is the user and what roles he have. Please see https://jwt.io/
We are designing security for a green field project with a UI web module (Spring MVC) - the client, and a RESTful services web module (CXF) - the server, to be deployed as separate war files in the same Websphere app server. The system should be secured with Spring Security, authenticating against LDAP and authorizing against a database. We have been looking for the best solution to share the security context between the 2 apps, so a user can authenticate in the web UI and invoke its AJAX calls to the secured RESTful services. Options found:
OAuth: seems overkill for our requirements, introduces a fairly complex authentication process, and reportedly some enterprise integration issues
CAS: would amount to setting up an enterprise SSO solution, something beyond the scope of our engagement
Container-based (Websphere) security, although not recommended by Spring Security, and we're not clear if this could provide a solution to our specific needs
We're looking for a simpler solution. How can we propagate the Security Context between the 2 apps? Should we implement authentication in the UI web app, then persist sessions in the DB, for the RESTful services to lookup? Can CXF provide a solution? We read many threads about generating a 'security token' that can be passed around, but how can this be done exactly with Spring Security, and is it safe enough?
Looking forward to any thoughts or advice.
You want to be able to perform the REST web services on the server on behalf the user authenticated in UI web module.
The requirements you described called SingleSignOn.
The simplest way to do it is passing the HTTP header with the user name during REST WS calls.
(I hope your REST client allows to do it).
To do it in secure way use one of the following:
Encrypt the user name in REST client and decrypt it in REST server
Ensure that the header is sent from the local host (since your application deployed on the same container)
Therefore, protect both application using SpringSecurity authenticate against LDAP.
In the first application (Rest Client) use regular Form Authentication
In the second application (Rest Server) add the your own PreAuthenticatedProcessingFilter:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#d0e6167
Edited
The “Authentication” is the process of verifying of a principal’s identity.
In our case both REST Client (Spring MVC application) and REST server (CXF application) verify an identity against LDAP. LDAP “says” OK or Not. LDAP is a user repository. It stateless and does not remember the previous states. It should be kept in applications.
According to my understanding, a user will not access directly to REST server – the user always access REST Client. Therefore, when the user access REST Client he/ she provides a user name and a password and REST Client authenticate against LDAP. So, if REST Client access REST server the user is authenticated and REST Client knows his name.
So, if request come to REST server with a user header name - REST server for sure knows that the user was authenticated and it should not authenticate it again against LDAP.
(The header should be passed in the secured way as described above).
Rest Server should take the user name, to access to LDAP and to collect related user information without providing of the user password (since the user already authenticated).