I'm evaluating WSO2 Identity Server and WSO2 API Manager.
I registered an API and an application on API Manager. I can call the resources successfully.
I could also add an user into Identity Server and log into that using oAuth authentication.
But, it's not too clear how I can use those two systems together. I would like to use API Manager to expose my API's to some applications. And, I would like to use Identity Server to log the final user. Is that possible? How can I "plug" those two systems?
I am not sure if that's the best way to do that, so, please, advice me.
Thanks
According to my understanding of your use case is you need to expose the API's securely. So you need to used WSO2 Identity Server and WSO2 API Manger. In addition to that you need the best approach for above use case.
With above two product we have below two option.
Configuring WSO2 Identity Server as the Key Manager in WSO2 API
Manager (This link gives a different version combination of both products)
Here we need to add key manger feature to the WSO2 IS.
Configuring the Pre-Packaged Identity Server 5.0.0 with API Manager
1.9.0
In here 1st option have manual configurations. But,2nd option minimized the manual configuration.
The purpose of using the Identity Server is not too clear. Is it to separate the authentication/authorization from the API Manager instance?
By default API Manager is shipped with a Key Management Server component that is responsible for all security and key related operations.This can be configured to authenticate users against a defined user store or multiple user stores. Authorization is based on oAuth 2.0. However, in a production deployment, we recommend that this component is deployed as a separate server instance so that it runs as an external Key Management Server.
This is done by simply using another copy of the API Manager distribution and configuring it as a Key Manager server node.
Hope this helps.
Regards,
Gillian
My understanding is,
if you wanted to use WSO2 API manager (AM) as an API gateway, you don't need a separate IS as AM included an IS engine with security mechanism included such as key manager.
If you need single sign on across all AM components, and you do NOT have other identity provider (IdP), you need a aeparate IS
However, if you do have a separate IdP, you don't need to install an IS server to implement SSO for AM, although the documentation from IS may suggest you do so. For example, a successful SSO implementation has been done with PingFederate/PingIdentity. See How to integrate WSO2 API Manager (AM) 1.10.0 with PingFederate SAML 2.0?
Related
What is the reference architecture for adding authentication and authorization to a mobile application. Do I need access tokens infrastructure or can I just use validation of a token data using private-public key pair. Do I need a dedicated Identity server(like wso2 identity server) incase I also want to release a developer API.
Thanks in advnace
Update
Things I have tried: I have worked on a project which uses the PKI based validation for every request(token data encrypted at client, token and encrypted data sent over to the server with every request and server decrypts to validate the client) this is a custom implementation, this I feel not the best way to do this, done some basic research to find the right way to do it. Found OpenAM and WSO2 IS, which can connect against multiple user store. They support token based authentication and policy based access control among other features.
What I'am looking for here: Am I on the right track, shall I goahead evaluating the two products, given that I also want to use the same platform another part of the same application which is web-based.
I would like to implement an architecture based on oAuth2 in which the token is generated by the WSO2 identity server (Auth Server) and the API manager is used as the Gateway (resource server).
I understood it's necessary to change the Identity_Server/repository/conf/carbon.xml and set the value false for the element <HideAdminServiceWSDLs>false</HideAdminServiceWSDLs> in order to enable the admin Service of token validation exposed by the Identity Server. Also I think it's necessary to configure the APIManager.xml to configure the API manager to check the token validation using a service exposed by the identity server.
But unfortunately the specific documentation is not available at https://docs.wso2.org/display/AM140/Configuring+api-manager.xm. Can someone help me understand how to achieve my goal ?
If it's correct to assume what you want is to, secure a exposed rest API with OAuth, using WSO2 IS, then the following link [1] will help you.
But since you are using WSO2 API manager, if there is no other restriction you can simply achieve this token generation functionality from API-manager itself. There is an OathTokenEndPoint exposed by API-M. You can call this endpoint with client-key and secret to get a token.[2]
[1] - http://movingaheadblog.blogspot.com/2014/02/securing-your-web-service-with-oauth2.html
[2] - https://docs.wso2.org/display/IS410/OAuth+2.0+Grant+Types+with+WSO2+API+Manager+Authorization+Code
I am new to windows azure development.
I am developing an application for hosting online tests.
This application needs to have multiple authentication options like Windows live ID, Facebook etc.
It also needs to have default form based authentication fed by the database in back end (simple User name and Password match).
Based on the authentication mechanism different permissions will be available to the user.
Can anyone please suggest how i should proceed on this?
Thanks
Do you really need forms authentication, or do you just need an application specific store where people can use a credential specific to your app?
I'd suggest researching Windows Azure Active Directory and Windows Azure Access Control Services together. You may create either an AD tenant for your application store and use it as an Identity Provider for ACS or you could host your own Secure Token Service and Identity Provider which uses your backend database as the user store also registered with ACS. This means that all of your authentication goes through the same process and allows for you to have your own user store, plus the social Identity Provider capability.
The key here is that you want try to avoid having forms authentication AND Social, but rather a mechanism where multiple Identity Providers can be used, including one of your own.
As Gaurav stated there are a ton of resources out there for this:
Understand the difference between WAAD and ACS.
Provisioning an Azure AD Tenant as a Identity Provider in ACS
Windows Azure Identity
There are also many blogs and MSDN documents talking about how to set these up.
If you start with the default "ASP.net MVC4 Web Application" template in Visual Studio you get a web application mini-sample with an AccountController that supports local and 'social' accounts out of the box. See documentation here. It is based on DotNetOpenAuth (a fantastic lib with terrible documentation) and a Microsoft implementation of an special MembershipProvider which lives in WebMatrix.WebData.
Regarding the Azure Access Control Service 2.0: I have no idea what the status of this service is but it looks to me as if MS itself tries to discourage developers form using this service since it was to deeply hidden somewhere under Windows Azure Active Directory in the documentation.
Do anybody know if there is any sort of API available for Cyber-Ark Privileged Identity Management to integrate it with an enterprise applications?
I think the answer might be 50% yes, 50% no. Definitely Cyber-Ark offers web services and an API for their Vault objects, so you should be able to retrieve passwords from the Vault from a trusted application. There is a paragraph of sales information on Cyber-Ark's website:
Cyber-Ark's comprehensive SDK provides an interface to the Vault objects that you can use to develop custom solutions that work with the Vault. Cyber-Ark provides a variety of SDK such as Command Line Interface, ActiveX API, .Net API and Web Services API
But beyond working with their Vault objects, I'm not entirely sure. I'm currently looking for more information on their Vault web services, and I think I need to register to be a Partner to get that information. I'll post a follow-up if I learn anymore.
You are suppose to purchase an API license per server to have read-only access to the vault for authorized applications.
They provide Java, C#, etc. libraries and you place authorization key material on the server to enable it access.
It is called CyberArk Application Identity Manager, an entire sub-product.
The only reference I could find:
http://lp.cyberark.com/rs/cyberarksoftware/images/ds-application-identity-manager-10-20-2014-en.pdf
CyberArk created Conjur. It is open source and free. It contains its own Vault and is intended for dynamic Application Access Management. In particular, Conjur and its upgrade Conjur Enterprise should secure the complete DevOps pipeline. The paid version can be integrated with the Vault solution (the PAS Core solution of CyberArk).
For static applications, CyberArk has the Credential Provider, Central Credential Provider and ASCP (I forgot the full name of it now). These solutions are agent based while Conjur is agentless. Because they are agent based, they are only intended for environments with comparatively slow changes as an agent needs to be installed on every server in order to provide the credentials from the Vault.
These solutions have REST API, CLI and SDK capabilities.
I am working on a security component to use with an ESB for a client with very concrete high level requirements:
Integrate into an existing IWay service manager version 5.5 ESB (there is no security system in the existing set up).
Provide authentication and authorisation level information from source data stored in an existing active directory server used for another system (preferably using LDAP).
Authentication and authorisation should be performed in the ESB as the interface for the ESB will be exposed to both internal and external clients so total control over the client is not possible.
The client can not be relied up to have a certificate to allow bilateral SSL authentication, however unilateral authentication, where the client checks to see he is hitting the correct server is possible, so HTTPS connections can be established.
The service should sit on Weblogic (but I will be happy to take suggestions regardless)
Further information:
IWay ESB is a commercial, closed and fairly poor solution, in version 5.5 it provides no out of the box solution which fits the requirements. it is also stateless so no sessions can be maintained other than using a cookie or some method similar to store information.
Current ideas:
To implement a SSO service that is added to the messaging bus which provides a identity provider, service provider functionality, so an initial authentication will provide a token, which can then be stored by the client and passed with each subsequent request to be authenticated and an authorisation level passed (which i believe to be a fairly standard design pattern).
Research has been carried out on SSO + SAML implementation, openAM, Shibboleth, CAS all seem to provide a too complete solution which caters more for a portal type architecture (like CAS) or from a system where the initial SAML identity token is received from another sever altogether and then brought to the system (like googles implementation of SAML for some of its services).
I have also looked into JBossESB, openESB and service mix solutions which seem to use a bespoke implementation of SAML which can't be ported onto Weblogic and Zxid which has limited documentation.
It is a complex undertaking so I am expecting more high level architectural styles and library/project suggestions rather than complete solutions. I am under the impression that this should be a reasonably common requirement, a authentication and authorisation service for a ESB which uses a token system to prevent credentials having to be continually entered or stored in plain text but I am unable to find much information, what am I missing?
Any further questions I would be more than happy to elaborate.
It seems a solution using SAML is a valid solution for when users potentially/do require to access a third party service on an ESB but don't want the third party service to be aware of the security specifics of the ESB and the credentials information of the user. This way the ESB may provide a SAML token provider where the user can get the ticket and transport it to different services for authentication, the services then check back with the token for authentication and possible authorisation information (with SAML2 only). In addition to this SAML could be used like open ID where users are managed externally and users go to the external token provider to get SAML tickets.
This was a valid solution for us as the the client wanted to be very aware of the users accessing the ESB and there was to be no plan to access third party services as it was a completely closed system.
We subsequently implemented a more custom SAAS (security as a service) mechanism for internal authentication and authorisation inside the ESB (I know it sounds bad but with iWay there are limited options) using spring security libraries and the remember me functionality which in our case met the requirements.
Low and behold our clients then changed their requirements and asked for integration with share point. This did however simplify the security model in our system because we then designed of the following:
iWay's primary security model is based around SSL certificates, it is possible to implement an SSL Provider which will manage certificates, you should therefore be able to supply share point with your SSL certificate and iWay with the public certificate and secure up the channels between the 2 servers, you can then manage users within iWay who can access the ESB on a system level and specify a share point user even specifying it's ip, this information is sent in plain text but over SSL and in our case sent between servers in the same network.
We are then leaving it to share point to authenticate users on a finer level so access to applications is managed at the share point 'portal' level and the only thing the ESB is vaguely aware of is the authorisation information which is passed with the client SOAP message and defines to what level the services can be accessed (this information is used on a service level).
Downsides to this solution are:
For each new client application developed to access the ESB interfaces a new ESB user must be configured so it is not possible for clients to be developed which can freely consume certain services on the ESB.
New clients have to implement the authorisation logic so the correctly formated authorisation string can be sent and understood by services.
Other points:
I am aware that the newer version of iWay provides a LDAP adaptor which should be able to communicate with AD so you can have your LDAP server attached to the ESB through this way so it could possibly be consumed by another client or services in the ESB but you would have to customise share point to access the information through the iWay business provider.
I also believe iWay 6 provides a SAML token provider which you could utilize (going back to what I said previous about the use of SAML) but I don't believe this fits in with a share point solution.
I would like to share more ideas seen as we are both doing the same thing, can you find me through my twitter account which is specified in my blog?
We are currently working with iWay Server Manager 6.0.1 and are also having difficulties identifying HOW to handle security for web services within this tool.
We want to build web services with it that have AD security in them like if we were using .NET Web Services and haven't found a solution. Even discussing this with the iWay staff did not clear it in our minds.
Now we have to connect to SharePoint web services and the issue will definitely be there.
Have you progressed with your situation? We would like some feedback from people using the tool on how they actually implement security with iWay.
Sorry for the delay... been quite busy over here...
Basically we've done many tests between iWay and SharePoint and we are not able to set it up to sent the NTLM credentials required by SharePoint. We've tried setting up channels, proxies and various other solutions within the tool...
We've placed a call to them to hopefully get some help...
Pascal