I read about the FI-Ware Identity Management GE.
I understand it acts as an OAuth2 Identity Provider enabling users to log in into applications using their FI-Ware site credentials.
The FI-Ware catalog site states this about the IdM :
In addition to providing a native login, IdM supports the integration
of multiple 3rd party authentication providers. Foremost, it supports
in a first step the configuration of preferred identity providers
through the administrators. The use of 3rd party IdMs lowers the entry
barriers for a native user to register, since the user can link to
her/his preferred IdM and use this account for authentication.
However, I could not find an explanation how this can be done.
Can anyone help ?
Thanks!
IdM doesn't support authentication with other IdP's. What that paragraph explains is that developers can use third party authentication in THEIR services using other IdP such us Google, Facebook or Keyrock. So what IdM supports is to allow other services to login using IdM authentication.
BR
Related
We want to utilize an external IdP that provides authentication services with Banno. Is there an option to configure it as OIDC IdP and redirect users to authenticate with it?
looking through Banno authentication framework I only see references to pulling data from Banno assuming user was already authenticated. Cannot find any documentation to how to configure redirect-to-IdP for authentation
We don't have documentation specifically about that use case, but we do have docs about our support for OpenID Connect Discovery: https://jackhenry.dev/open-api-docs/consumer-api/api-reference/v0/oauth-and-openid-connect/#openid-connect-discovery
We're aware of folks using Amazon Cognito, Kong, and Firebase with our OIDC Discovery endpoint.
Note that those services may not support Proof Key for Code Exchange (PKCE). If that's the case, then you'll have to have Banno Admin for your financial institution turn off the "Require PKCE" option in the External Application.
First of all, I'm using the Telefonica implementations of Identity Manager, Authorization PDP and PEP Proxy, instead of the Fiware reference implementations which are Keyrock, AuthZForce and Wilma PEP Proxy. The source code and reference documentation of each component can be found in the following GitHub repos:
Telefonica keystone-spassword:
GitHub /telefonicaid/fiware-keystone-spassword
Telefonica keypass:
GitHub /telefonicaid/fiware-keypass
Telefonica PEP-Proxy:
GitHub /telefonicaid/fiware-pep-steelskin
Besides, I'm working with my own in-house installation of the components, NO Fi-Lab. In addition to security components, I've an IoT Agent-UL instance and an Orion Context Broker instance.
Starting from that configuration, I've created a domain in keystone (Fiware-Service) and a project inside the domain (Fiware-ServicePath). Then I've one device connected to the platform, sendding data to the IoT Agent behind the PEP Proxy. The whole device message is represented as a single Entity in Orion Context Broker.
So, the question is:
How can I restrict a specific keystone user to access only to the entity associated to this device, at the level of the Orion Context Broker API?
I know that I can allow/deny user acces to specific API via keystone Roles and XACML Policies but that implies that I should create one Policy per User-Device pair.
I could use some help with this, to know if I'm on the right way.
I do not think Access Control can be done to Orion without Security GEs. Each GE has a specific purpose and access control is not one of the Orion's purposes.
As stated in the Security Considerations from Orion documentation:
Orion doesn't provide "native" authentication nor any authorization mechanisms to enforce access control. However, authentication/authorization can be achieved the access control framework provided by FIWARE GEs.
Also, there is something related in another link:
Orion itself has no security. It’s designed to be run behind a proxy server which provides security and access control. Used within the FIWARE Lab, they run another service build on node.js, “PEP Proxy Wilma”, in front of it. Wilma checks that you have obtained a token from the FIWARE lab and put it in the headers.
Besides, the link below can endorse my opinion about Orion and access control:
Fiware-Orion: Access control on a per subscription basis
My opinion is that you are in the right way using the other security components.
About "create one Policy per User-Device pair" as you mention, maybe it would be better you thought about "group policies" instead.
We want to use the FIWARE IdM, both Keystone and Horizon. Specifically during sign-up we want to
create a user
add that user to an organisation
authorise the user for an application
We have installed Keystone and Horizon using the latest KeyRock docker image on the docker hub.
When a new user signs up:
a 'cloud organisation' is created.
By default, the 'provider' and 'purchaser' roles are present
and the 'Store' application is assigned to the user (although i cannot verify this).
We can add the user to an organisation by hand, and authorise the user for an application by hand in the KeyRock UI.
However this does not make any sense for our local installation.
How can we prevent Horizon from creating the cloud organisation upon user sign-up?
How can we assign a default application authorization upon user sign-up?
-- Edit --
It’s becoming increasingly clear to me that the way KeyRock is implemented is primarily useful for setting up your own Fiware labs environment, as opposed to setting up a generic Identity management service. If we use KeyRock, we will be stuck with cloud organisations, stores etc. Far from being a Generic Enabler (GE), KeyRock seems to be a “Fiware Labs” specific enabler.
All the GE documentation references KeyRock as the reference Identity Management GE. Therefore we (and i assume others too) have followed the documented architecture and configuration to link to KeyRock from:
Wilma PEP Proxy GE
Wirecloud Application Mashup GE
Because of the inbuilt Fiware Labs functions of KeyRock, we are having a really hard time applying Wilma PEP Proxy and Wirecloud Application Mashup to our use cases.
If we decide to use Keystone instead, we will lose
OAuth2 support
Permissions
sign-up, admin and login screens.
Is anyone else having this problem?
How have they tackled it?
-- SCIM API --
Attempt at using the SCIM API is described here: Fiware KeyRock SCIM API bug: _check_allowed_to_get_and_assign() got an unexpected keyword argument 'userName'
I want to use Identity Management - KeyRock GE in the FI-LAB portal (https://github.com/ging/fi-ware-idm/wiki/Using-the-FI-LAB-instance). It's said that this GE is already deployed on FI-LAB.
Can I use this GE just to control an access to my application or is there any other usage of this GE?
Also, how will it work (step-by-step) when a registered user wants to login into my application?
You have two options here. You can use the current instance of the IdM in order to offer you the authentitation and authorization or you can install your own instance of Keyrock. I recommend the first one in which you just need to create an account in the FIWARE Lab and use the keyrock to offer you security access to your applications. I think that you can go to this presentation Adding Identity Management and Access Control to your applications. in order to have deep details about the different steps that you have to follow to do the first scenario.
I'm starting to work with CAS on my company. This is totally new for me, so I had to read lot of documents and how to's to have an idea of how CAS works.
So, we have to provide a single sign on service in our server to a company with two different applications. One of those, uses SAML2.
My CAS server is now working against a MySQL database, so I'll have the users of those 2 apps on my database to provide authentication service.
What I don't get clear is about SAML. All the tutorials I've read about SAML2 integrated with CAS 4.0.0 are using Google Accounts. I don't know why! I have some SAML2 configuration on a xml on my CAS directories, but I don't know how to prove if it's working or not.
If you are going to authenticate both of the applications using your single database, CAS is enough, SAML not required. With SAML you can connect to an external application(which supports SAML), both might be having their own internal authentication, but they will commnicate each other through SAML2 protocol/agreement
CAS is ideal ,if you want to setup a web single sign-on to different web applications (exclusively for a single institution), which all use the same authentication (DB, LDAP or whatever). With this the authentication will be centralized for all these different applications.
For users from another external institution to use your web application, SAML would be the choice, provided the External application also should support SAML.