The instructions for providing FIWARE based authentication for Wirecloud suggest installing KeyRock (a frontend/backend combo of the Horizon/Keystone GE). Is the frontend (Horizon) really necessary if the only application to be secured is a Wirecloud instance (and possibly some backend services). The point is to avoid, if possible, to have to configure/style/maintain etc. a second frontend. Is it possible to authenticate directly using a Django plugin like this? Pros and cons?
WireCloud is currently linked to the use of django.contrib.auth, any authentication plugin based on it should work. Moreover, the instructions for using KeyRock are using python-social-auth so, in fact, you can use it for authenticating using any of the backends supported by python-social-auth: GitHub, Twitter, OpenId, ...
In that regard, I don't see any problem in the use of the plugin you are proposing (Although I have not tested it).
The advantage of using the KeyRock backend provided by WireCloud is that it enables operators and widgets to propagate the credentials to third-party services using KeyRock for authentication (e.g. Orion Context Broker, Object Storage, ... and in general, any service behind a PEP proxy).
Related
We are trying to integrate a Django application with an OpenID Connect (OIDC) provider as a Relying Party. The provider isn't a major vendor, and thus doesn't have custom-built packages, so we are leveraging Authlib. This works, but I'm stressed about the amount of custom code we are having to put in to manage the session and redirects and whatnot.
I have experience in the Ruby and Node.js worlds, and those communities have the general-purpose authentication tools OmniAuth and Passport, respectively. Is there an equivalent for Django?
Closest I've found is mozilla-django-oidc, which I may try — curious if there are others I'm missing. Surprised I haven't come across anything that hooks into the Django authentication system.
Thanks!
I would like to implement automatic rules of API Goverment in a WSO2 API Manager platform like, for example, validating context with a regular expresion, or version numbering or API name or API resources endpoint naming or parameters, etc.
I checked in version 2.6.0 (and previous versions of major 2) that it can be done in jaggery apps of publisher, but this is a mix of data and presentation (view structure with js and html) and it is not a clear and right way to implement it.
Is there any rules engine or other dedicated mechanism to do it? If not, is it in the roadmap of WSO2 AM to add this kind of features? It would be great.
APIM 3.x onwards UIs are implemented using react and backend services are exposed via REST APIs. SO from this version onwards, this is clearly separated. UI level validations can be changed in the React and if there are any additional validations required, REST API interceptors or workflow interceptors can be used to enforce any validations.
Just to clarify my understanding of what Torii provides for client side static apps:
OAuth 2.0's Implicit Grant workflow is the only OAuth workflow which works in client side static apps.
Torii only supports this via torii/providers/oauth2-bearer, which returns tokens not codes.
If 1. and 2. are true, then I suppose all client side static apps which use Torii would only use the oauth2-bearer approach. The rest of the providers in Torii, like stripe-connect etc. which are code workflow based would need server support to get an AccessToken based on the code.
Is this right?
Thanks in advance.
Some of the concepts in Torii can be a little confusing to understand. Because it's so flexible, the answer to most questions is "it depends".
Your understanding is basically correct:
Yes, the only useful OAuth workflow which does not require a server with a shared secret is Implicit Grant.
Yes, the bearer provider does not require you to run a server. Neither does the facebook-connect provider, or any custom provider which uses the same approach.
Serverless apps using Torii cannot use an Authorization Code workflow, and would need an authentication mechanism which returns an access token. This is likely to be using the oauth2-bearer provider, but you could use facebook-connect or any other similar approach.
I am trying to implement multiple login options in my ember-cli site (so you can authenticate via facebook, google, or my own oauth2 server). However, I'm a little at a loss as to the right way to accomplish this. As far as my research goes, I can see that there are multiple ways to do this using ember-simple-auth.
The first option is to simply use ember-simple-auth-oauth2, and create authenticators that extend that for each login method. This is a combination of the Authenticated Account and Multiple External Providers examples provided by ember-simple-auth. Obviously, this would mean writing all my authenticators myself including the ones for facebook/google.
The second option I see is to use ember-simple-auth-torii to authenticate each of my login methods, as in the Torii example provided by ember-simple-auth. However, I simply cannot find a good oauth2 example to help me create a provider for my custom oauth2 server. If anyone could help me out with this by showing me how to add a custom oauth2 provider to ember-simple-auth-torii, I would appreciate it.
Finally, the last option (that I can see) is a combination of the two above - Using ember-simple-auth-torii authenticators for google/facebook, and a ember-simple-auth-oauth2 authenticator for my own server. Obviously, I don't really want to rely on 2 separate ember-simple-auth packages, but if I have to I can (I'm assuming doing this would work?).
If anyone could pipe in on these methods or suggest a new one to allow me to do oauth2 authentication via facebook, google, and a custom server, I'd appreciate it.
Using both packages is the way to go. The Ember Simple Auth packages are built so that you always include the base package (ember-simple-auth) plus any additional packages for authentication strategies etc. that you want to use. If you e.g. want to use the OAuth 2.0 package to authenticate against your own server plus the torii package to authenticate against Facebook, Google+ etc. then you simply include both packages. There will also be no duplicate code that you're requiring as the common functionality is in the ember-simple-auth package and the ember-simple-auth-oauth2 as well as the ember-simple-auth-torii packages only include the code that's specific to the respective authentication strategy.
What is the current, recommended way to setup a WSO2 API manager to use SSO against a Shibboleth IDP?
Our organization has an existing SSO infrastructure built around Shibboleth’s IDP which we would like to integrate into our API Manager installation. Ideal Use Case:
User navigates to API Manager Store.
User is redirected to Shibboleth IDP Login page.
If one doesn’t exist, an API Manager Account is created and assigned the Subscriber role.
User is returned to API Manager and logged in. “Signed-in-as:” renders a reasonable user name (i.e. not a GUID).
I’m aware that there is an included SAML2 authenticator component to the API Manager but it is limited in features, specifically it does not handle Encrypted Assertions, Using specific attributes for username/display name and automatic user creation.
I understand that we could write a custom authenticator, however we would rather avoid creating another code base that needs to be maintained and doesn’t have community support. If a simpler solution cannot be determined then this will likely be what we do.
What I am currently investigating is delegating all user management for the API Manager to a WSO2 Identity Server. It IS would delegate authentication to Shibboleth and auto provision users before returning to the AM. The IS seems like it could address all of the issues mentioned above.
Firstly, is this an appropriate strategy? If so, how is it recommended that the AM and IS be configured?
Should the IS and AM both point to the same JDBC Database or should the AM point to the IS’s LDAP server?
Regarding the AM authenticator which is pointed to the IS, should I use SAML or OAuth, or is there a better/simpler one?
Shibboleth IDP v2.4 – SAML2 with Attribute Push preferred.
WSO2 API Manager v1.6.0
WSO2 Identity Server v5.0.0
Here's the results of my research, for anyone interested:
1) This is an appropriate strategy. The new features in the 5.0 release of Identity Server are mainly centered around this scenario. And the 1.7 release of AM also includes features to facility this setup. Finally I've heard from the developers that they intend to push this integration even further in the next few releases.
2) As of AM 1.6 there was a bug which made it almost required to share the same Primary JDBC user store. As of 1.7 it should be more open.
There does not seem to be a preference from the people at WSO2 between LDAP and JDBC (except that the default H2 DB is not designed for production environments), however if you are choosing between installing a DB or Open LDAP for this, a LDAP server seems more suited to the choice.
3) It's best to use SAML for communicating between the two when the goal is to present the user with a UN/PW screen. When the goal is to login with pre-issued tokens then OAuth. The API Manager and IS use both protocols behind the scenes, but the answer to this particular question seems to be SAML.
In the future WSO2 plans to expand the "Trusted IDP" feature of their products, which will streamline this process (and use SAML behind the scenes).