We are running CAS Server 5.2.2 with 2 authentication handlers. One of them is a custom authentication handler where we are able to manage any kind of scenario. The other one is setup to delegate authentication to another identity provider which validates several types of credentials (digital certificates, ...).
Our problem is with the delegated authentication: the integration via oauth2 works fine and we release Principal attributes using a groovy script. Our new case is the following:
After a successful delegated authentication we need to evaluate some attributes and depending on their values mark the final authentication as failed.
How can we achieve this? We have tried to throw an Exception (registered in application.properties) in the groovy script that releases the Principal attributes but it does not seem to work.
Related
I am trying to set up two instances of Spring Cloud Gateway to work with IdP to authenticate with the oAuth2 Authorization Code flow. The load balancer in front of the two gateway instances is round robin fashion.
One of the challenges is to share the session between the two Spring Cloud Gateway instances (if no session sharing, after the user successfully logged in IdP and redirected to the instance #2, it will have problem because the instance #2 doesn't have the session information that generated by instance #1 who redirect the user to the login page). And I don't want to use sticky session fashion in load balancer.
I can manage to use Redis to store the sessions by using dependencies org.springframework.boot:spring-boot-starter-data-redis and org.springframework.session:spring-session-data-redis, but I failed to use MySQL to do it (and I have to use MySQL to do it for cost consideration).
I tried this sample, which uses spring boot starter web, it does able to use MySQL to store the sessions.
But when I tried to replace the dependency org.springframework.boot:spring-boot-starter-web with org.springframework.cloud:spring-cloud-starter-gateway:3.1.0 and configured the spring.session.store-type: jdbc, I encountered below error:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.boot.autoconfigure.session.SessionAutoConfiguration$ReactiveSessionRepositoryValidator': Invocation of init method failed; nested exception is org.springframework.boot.autoconfigure.session.SessionRepositoryUnavailableException: No session repository could be auto-configured, check your configuration (session store type is 'jdbc')
Any idea to solve it? Many thanks!
I have installed CAS6.4 and CAS Management .
I am able to access https://CNNAME/cas/login & it successfully login .
I could also Login to https://hostanme/cas-management/ and it redirect back to cas management.
I have added service URL in cas management as below :
^(http|https)://CNNAME*/**
http*://hostname2/*
But when i access these URL, i get error as
Application Not Authorized to Use CAS
The application you attempted to authenticate to is not authorized to use CAS. This usually indicates that the application is not registered with CAS, or its authorization policy defined in its registration record prevents it from leveraging CAS functionality, or it's malformed and unrecognized by CAS. Contact your CAS administrator to learn how you might register and integrate your application with CAS.
In the logs i get error as :
2021-03-01 07:15:39,111 WARN [org.apereo.cas.services.RegisteredServiceAccessStrategyUtils] - <Unauthorized Service Access. Service [https://hostanme/callback] is not found in service registry.>
I have been struggling to get this solved for for days, could someone please help me with this.
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'
As of now, we have an authentication service using Spring Security OAuth2 which implements the following grant types: client_credentials and password.
To obtain a token, a client (potentially an HTML5 SPA client) would have to store the client_id and secret to obtain a bearer token with either the client_credentials or password grant type. For this case, it's not very safe as anyone the client_id and secret would live within the HTML5 apps source and anyone could obtain it.
Is there a different flow for this, other than client_credentials or password?
Generally speaking, for SPA s the recommended authorization protocol is OAth with Implicit grant.
You can read a bit more about how that is implemented in Azure Active Directory (it is free) here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-understanding-oauth2-implicit-grant
and here: https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-implicit