I have set the wso2 api manager 1.6 and I have a rest api at the backend to which this is calling.
I know that wso2 provides Oauth 2.0 support. but I am not able to find out how scopes are handled.
This is my specific scenario:
I have a client application to which i want to assign scope view Photos. And another client application with a scope to delete photos.
Now in the Api manager I want to restrict access to the delete api only to the client application which has the delete photos scope.
How can this be handled in wso2?.
One approach is to explicitly get information about scopes in your application and perform manual validation (or through some framework, like Spring Security in Java world).
Scope information for oauth token can be found by sending request to validation web service at Identity Server (or Api Manager server, if you do not have separate IS).
Validation service endpoint is: services/OAuth2TokenValidationService/
WSDL file for this SOAP service can be found in their repository
EDIT:
Since Api Manager 1.7 you can define this security settings in manager itself. Check out this blogpost for details: http://nuwanzone.blogspot.ru/2014/06/oauth-20-scopes-with-wso2-api-manager.html
Related
I've got a SPA application which gives statistics and information to anonymous users. It is a react spa app and will consume backend REST Web API(.net core). These data are not specific to users, therefore the information is freely available and no user authentication is required. However, I don't want my Backend Api layer to be exposed to the internet (i.e not use by anonymous applications such as postman, rest clients, etc). I'm familiar with the Client credential flow (OAuth) but I can't use it for this application because there is no concept for user login in this application.
What would be my best options that limit access to my API layer to anonymous applications (i.e postman, etc), or is it not possible at all?
You can't use client credentials flow for your SPA. Anyone would be able to download your SPA, extract the client id and secret and use it to call your API.
If you do not want to authenticate your users, there's no good way to protect your API. Move your SPA to a traditional web application hosted on a server to protect it using client credentials flow.
It's not possible to make an API accessible to a public client (your SPA) without also making it accessible to users making API calls from Postman or custom code. It's possible to do the reverse, only because of the limitations that browsers put in place.
Depending on what you're trying to achieve, you could use something like reCAPTCHA to validate that the users of your API are humans, not scripts. That along with human-scale rate limiting would probably filter out most of non-app users.
I'm developing an authentication/authorization system in Node Js for a microservice based application.
I read some articles and documentation about the OAuth2 standard but I need some clarification for my use case.
Basically OAuth2 has some actors like:
Resource owner (user)
Client app (a web application in some OAuth2 grant flows like authorization code, implicit, password)
Authorization server
Resource server (service I want to access to)
So in my database I store a client (web application) with its client_id and client_secret.
Let's suppose that one of my microservice needs to access data from another microservice. Both of them espose a REST Api.
There is no interaction with user, all is done in the background. In this case I would use the client credential flow.
Following OAuth2 rules, both of them are resource servers but in the same time it looks like they are client apps as well.
So should I register them in the client DB table/collection with client id, secret etcetera or did I make some mistakes?
Thank you
If I understood your question correctly, the caller micro-service is your client and the one that is being called is your resource. A lot depends on what type of micro-service communication pattern have you implemented. If you are implementing an "API Gateway" pattern, then your Gateway is always client and all other micro-services can be treated as resources. But if your micro-services can call each other then like you mentioned each one of them have to be registered as client and resource at the same time.
We had an web application that already using form-login provided by spring-security, say, ERP. Now we are considering make ERP as an oauth2 authorization server to authorize other internal services.
The ERP still serving its business and all access are required to be authorized, but doesn't based on access token so I think it is not an oauth2 client. It does NOT serve as an Resource Server, neither.
I have read many article about how to setup oauth2 authorization server and develop an application using it. According to this comment I feel it is possible to make ERP authorizing other services without explicit setup a standalone authorization server (it's our final goal but not now):
Within the context of OAuth2, we can break things up according to the component you're implementing:
Client app: it's likely that server based OAuth2 Client app already uses HttpSession and therefore it makes sense to use Spring Session and benefit from all the goodies it brings
Resource Server app: since this component provides a stateless API that's authenticated against using an Access Token as a bearer, the HttpSession is not used and therefore Spring Session isn't suitable as well
Authorization Server app: it's highly likely that this already uses HttpSession so similarly like with OAuth2 Client app, it makes sense to use Spring Session and benefit from all the goodies it brings
What I'm going to do is add the #EnableAuthorizationServer into config, but I have no idea what's the next step.
My question is can I convert an existing application into an authorization server while keeping its original service unchanged? Where and How should I start?
I just found it's not that hard to integrate OAuth2 into existing system, below is what I did to make it work.
In short: EnableAuthorizationServer won't break anything exists, but they don't coming from nothing, either.
When I put on the EnableAuthorizationServer, spring-security-oauth2 gives me following endpoing:
/oauth/authorize
/oauth/check_token
/oauth/token
/oauth/confirm_access
/oauth/error
Those endpoints provide necessary functions to make OAuth2 works, and I just need to apply access control onto those endpoints with existing form login mechanism (probable not the check_token one).
Since this system didn't act as resource-server role, the authorization part is done.
I am trying to use this username in my code but I do not know if it is provided in the environment variables. Thanks!
Additional information: I am using using PingFederate and Ping One.
My website is based on C sharp and it used to get the windows environment variable for username. now I want it changed to the user logged in through ping identity.Is it possible to do so and in that case which SDK should I get (I am assuming the .net integration kit right?)?
As a .NET hosted application on IIS, your application would be considered the Service Provider (SP). In this architecture PingFederate is the Identity Provider (IdP). This is a brokered authentication design pattern, or more commonly known as Single Sign-On (SSO). When PingFederate authenticates the user, a token is sent to your application that would contain the username. The code (or library) within your application would process the token and then read out the username.
Here’s a list of options that you could pursue to solve your problem:
WS-Federation protocol using the Windows Identity Foundation (WIF) libraries. The config on the PingFederate side is very simple, and you just have to integrate the WIF libraries on your side. Once the WIF libraries and associated web.config configuration is established, you read the claims object passed to your application.
OpenID Connect (OIDC) protocol using the OWIN middleware. This is also a native MS solution that leverages an open standard. It will require that you have some understanding of OWIN/Katana, as examples are not exactly exhaustive online. PingFedeate supports the OIDC protocol, which is also a very straight forward configuration.
PingFederate Agentless Integration Kit. The integration kit is installed on PingFederate and is easy to configure. It is essentially a REST interface between PingFederate and your application to provide a JSON object with the identity information including username. Your application would need to implement the REST APIs to PingFederate.
PingFederate .NET Integration Kit. This solution implements the PingFederate Opentoken solution for exchanging attributes between your app and PingFederate. The .NET code libraries for handling the Opentoken are provided to you by the integration kit, you just have to integrate them into your code baseline along with about 10 lines of code to read the OpenToken to get username. Configuration on PingFederate is simple.
I am currently developing a distributed application using Ruby, Ruby on Rails, Sinatra and pure Rack web services.
I will have few services (RESTful , not SOAP based) which will communicate using JSON and I would need a way to secure and verify the identity of each of those services during the communication between them, so no one could pretend to be a service and make requests to the other services.
The core idea is to treat other services as "users" and be able to verify their identity and limit their access to data if necessary.
So the question is how to do this using only Ruby and how to manage effectively the service identities and their access rights.
Should I build some additional authentication service usable by the services ?
Should I build internal gems to provide some connection middleware with keys/shared secrets ?
Is there maybe some other way to do this?
I would generate an application id and secret that you could pass with each request. Since you are not dealing with other users and just applications try looking into authentication tokens with devise.
I think OAuth is a protocol that is commonly used for web service - to - web service runtime authentication, especially with RESTful APIs.