I've been dropped into a hot potato project...an external entity produced a SOA architecture and we need to implement it now.
Using Drupal as a CMS and starting point of the architecture.
Here's what I think we need to do:
Authentication server
People register through the drupal site. We'd like to reuse the identity created for other (future) services, through a REST API
a) Can I add users to WSO2 Identity Server via a (REST) API?
b) Can I query WSO2IS to authenticate users via a (REST) API (creating a SSO env)?
c) Can I create re-usable profiles in WSO2IS, accessible through a (REST) API?
d) Can I authenticate drupal access via WSO2IS through a (REST) API?
e) Can I query the XACML policies via a (REST) API so that access to a requested service can be evaluated?
Other REST APIs we're going to build would use the OAuth functionality of WSO2
The architecture mandates each an authentication, a profiles and a policy (authorization) with XACML (...) module. The alternative is to build it all ourselves but I think we won't have the time for this, but I need to understand if we can do the above mentioned things to make a decision if WSO2IS is a good choice for our needs.
I have read the available documentation, browsed the help system, installed WSO2IS and checked out the interfaces, but couldn't find the responses. The only thing I managed to do is create the OAuth server.
Please find my answers..
a) Yes.. WSO2 Identity Server supports SCIM which is the standard approach for identity provisioning. Also there are web service APIs, that expose user management functions. You can front those web service API using WSO2 APIM and can expose as REST API.
b) Yes.. Apart from REST and web service API, Identity Server supports for authentication methods such as SAML2SSO, OpenID, IWA and so on.
c) Yes.. same as a) you have both options SCIM or Web service API fronted with APIM
d) There is an authentication framework in the WSO2IS, that users can be authenticated with different server.. Basically WSO2IS can act as federated IDP that application knows only to talk to WSO2IS.. WSO2IS can authenticate users from any other IDP, It can be drupal as well
e) Yes.. XACML is supported by WSO2IS... Its PDP API has been exposed via web service API.. but not as a REST API.. but as i mentioned earlier, you can expose it as REST using APIM. However REST support for XACML would be available with the further release
Related
we am trying to use open ID connect (OIDC) for authentication and authorization (AnA) for our micro-service architecture based on spring-cloud framework
As a part of requirement we want to achieve following:
Integrate (OIDC) with SSO Federation as a Identity provider which we are using federation to authenticate users (staff id)
How to customize access_token which in turn will be provided by a micro service (Authorization service)
I am looking at MITREid Connect as its based on spring framework and spring security
https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server
As a resutl of that, all requests to our services have to go through (OIDC) for (AnA)
I also check on https://cloud.spring.io/spring-cloud-security/ as I understand the Zuul server will get an access_token to relay to proxied services. But our scenarios are different as we want to expose other micro-services to external parties as well so that we want to have secure our services.
Any advices is highly appreciated.
I implemented authentication and authorization using Identity server 4 with OIDC to allow clients accessing our application to get the necessary tokens to access our resource server (web APIs). This is the current architecture :
Identity Server 4 using my custom DB to authenticate users
Resource APIs (ASP.NET Core)
Angular 2 front end
I need to implement SSO, where users from other systems will pass SAML2 assertions from their identity providers to allow them to access our resource APIs without logging in to our application.
I have some confusion about where this step will happen, and what will be the workflow, will our identity server be involved in this process and how to implement that using Identity Server 4.
Right now there is no SAML2 support for ASP.NET Core.
If you are using IdentityServer3, you can act as a SAML2 SP via the Kentor authentication middleware. This is not available for ASP.NET Core yet.
Generally speaking - you cannot use SAML2 to secure APIs - it is a protocol for web based SSO - not API access.
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.
I want to implement SSO using Thinktecture Identity Server V3. The applications the I want to use this SSO are asp.net MVC apps. I was going through samples provided on the thinktecture wiki and am able to see two approaches:
1- Resource owner(providing credentials through application and calling Identity server using OAuth2Client Apis)
2- Using Owin middleware(Startup class) to call the Identity server.
In my case I wanted to calling Identity server login, but without using Owin. Do you any hints/sample on how to do that.
Thanks
If you don't want to use the Microsoft OpenId Connect middleware (and as a result OWIN) in your clients, you could initiate the login flow yourself by redirecting the user to the authorize endpoint.
Authorize endpoint: http://thinktecture.github.io/Thinktecture.IdentityServer.v3.Documentation/docs/endpoints/authorization.html
They guys behind IdentityServer have a client example showing some of the concepts if you want to handle it all yourself:
https://github.com/thinktecture/Thinktecture.IdentityServer.v3.Samples/blob/master/source/Clients/MvcFormPostClient/Controllers/AccountController.cs
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).