I'm deploying a shibboleth v4 idp for SSO to protected network resources with Shibboleth SPs (Service Providers).
I want to define simple rules like that:
SP group one: SP-A and SP-B must be in the same SSO context (no re-authenticaton requeired between resources of SP-A and resources of SP-B)
SP group two: SP-C and SP-D must be in the same SSO context (no re-authenticaton requeired between SP-C and SP-D)
re-authenticaton required between SP from differents groups.
I'm working on relying-party.xml, writing something like this:
<!-- Example matching two SPs (group one) -->
<bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'SP-A', 'SP-B'}}">
<property name="profileConfigurations">
<list>
<!-- Your refs or beans here. -->
<bean parent="SAML2.SSO">
..I suppose I need to define something here, but what?
</bean>
</list>
</property>
</bean>
<!-- Example matching two SPs (group two) -->
<bean parent="RelyingPartyByName" c:relyingPartyIds="#{{'SP-C', 'SP-D'}}">
<property name="profileConfigurations">
<list>
<!-- Your refs or beans here. -->
<bean parent="SAML2.SSO">
..I suppose I need to define something here, but what?
</bean>
</list>
</property>
</bean>
This road is correct? With respect to this example what rule should I write?
Related
I am Using Shibboleth as IDP
For starters, how do i configure IDP to pick an authentication mechanism based on sp
like
SP1- Database Authentication
SP2- External Authentication
SP3- LDAP Authentication
We can configure the behaviour required in replying party.xml
<bean parent="RelyingPartyByName" c:relyingPartyIds="https://sp.example.org">
<property name="profileConfigurations">
<list>
<!-- Your refs or beans here. -->
</list>
</property>
</bean>
And
we can specify the desired authentication mechanism as
<bean parent="SAML2.SSO" p:authenticationFlows="#{{'Password'}}" />
which will be like
<bean parent="RelyingPartyByName" c:relyingPartyIds="https://sp.example.org">
<property name="profileConfigurations">
<list>
<bean parent="SAML2.SSO" p:authenticationFlows="#{{'Password'}}" />
</list>
</property>
</bean>
I'm using Cas 3.5.2 with 2 different authentication handlers, let's say 'weak' and 'strong'.
Based on the authentication done by a user, I'd need to tell to the federated service asking for authentication if a weak or strong authentication was performed by the user.
I am already setting some attributes to the user principal customizing the casServiceValidationSuccess.jsp page, Is there any way in this page to know which authentication handler was used to authenticate the user?
Best regards,
Dariush
Edit
Following my deployerConfigContext.xml
As reported I have 2 different authenticationHandlers, one based on lppe, another on a custom class.
What I'd need is just knowing in casServiceValidationSuccess.jsp page which authHandler was successful.
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to Jasig under one or more contributor license
agreements. See the NOTICE file distributed with this work
for additional information regarding copyright ownership.
Jasig licenses this file to you under the Apache License,
Version 2.0 (the "License"); you may not use this file
except in compliance with the License. You may obtain a
copy of the License at the following location:
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<!--
| deployerConfigContext.xml centralizes into one file some of the declarative configuration that
| all CAS deployers will need to modify.
|
| This file declares some of the Spring-managed JavaBeans that make up a CAS deployment.
| The beans declared in this file are instantiated at context initialization time by the Spring
| ContextLoaderListener declared in web.xml. It finds this file because this
| file is among those declared in the context parameter "contextConfigLocation".
|
| By far the most common change you will need to make in this file is to change the last bean
| declaration to replace the default SimpleTestUsernamePasswordAuthenticationHandler with
| one implementing your approach for authenticating usernames and passwords.
+-->
<!--beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:sec="http://www.springframework.org/schema/security"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.1.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.1.xsd"-->
<!--
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.1.xsd"-->
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:c="http://www.springframework.org/schema/c"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:util="http://www.springframework.org/schema/util"
xmlns:sec="http://www.springframework.org/schema/security"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.1.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.1.xsd
http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.1.xsd">
<!--
| This bean declares our AuthenticationManager. The CentralAuthenticationService service bean
| declared in applicationContext.xml picks up this AuthenticationManager by reference to its id,
| "authenticationManager". Most deployers will be able to use the default AuthenticationManager
| implementation and so do not need to change the class of this bean. We include the whole
| AuthenticationManager here in the userConfigContext.xml so that you can see the things you will
| need to change in context.
+-->
<bean id="authenticationManager"
class="org.jasig.cas.authentication.AuthenticationManagerImpl">
<!-- Uncomment the metadata populator to allow clearpass to capture and cache the password
This switch effectively will turn on clearpass.
<property name="authenticationMetaDataPopulators">
<list>
<bean class="org.jasig.cas.extension.clearpass.CacheCredentialsMetaDataPopulator">
<constructor-arg index="0" ref="credentialsCache" />
</bean>
</list>
</property>
-->
<!-- remember me -->
<property name="authenticationMetaDataPopulators">
<list>
<bean class="org.jasig.cas.authentication.principal.RememberMeAuthenticationMetaDataPopulator" />
</list>
</property>
<!--
| This is the List of CredentialToPrincipalResolvers that identify what Principal is trying to authenticate.
| The AuthenticationManagerImpl considers them in order, finding a CredentialToPrincipalResolver which
| supports the presented credentials.
|
| AuthenticationManagerImpl uses these resolvers for two purposes. First, it uses them to identify the Principal
| attempting to authenticate to CAS /login . In the default configuration, it is the DefaultCredentialsToPrincipalResolver
| that fills this role. If you are using some other kind of credentials than UsernamePasswordCredentials, you will need to replace
| DefaultCredentialsToPrincipalResolver with a CredentialsToPrincipalResolver that supports the credentials you are
| using.
|
| Second, AuthenticationManagerImpl uses these resolvers to identify a service requesting a proxy granting ticket.
| In the default configuration, it is the HttpBasedServiceCredentialsToPrincipalResolver that serves this purpose.
| You will need to change this list if you are identifying services by something more or other than their callback URL.
+-->
<property name="credentialsToPrincipalResolvers">
<list>
<!--
| UsernamePasswordCredentialsToPrincipalResolver supports the UsernamePasswordCredentials that we use for /login
| by default and produces SimplePrincipal instances conveying the username from the credentials.
|
| If you've changed your LoginFormAction to use credentials other than UsernamePasswordCredentials then you will also
| need to change this bean declaration (or add additional declarations) to declare a CredentialsToPrincipalResolver that supports the
| Credentials you are using.
+-->
<bean class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver" >
<property name="attributeRepository" ref="attributeRepository" />
</bean>
<!--
| HttpBasedServiceCredentialsToPrincipalResolver supports HttpBasedCredentials. It supports the CAS 2.0 approach of
| authenticating services by SSL callback, extracting the callback URL from the Credentials and representing it as a
| SimpleService identified by that callback URL.
|
| If you are representing services by something more or other than an HTTPS URL whereat they are able to
| receive a proxy callback, you will need to change this bean declaration (or add additional declarations).
+-->
<bean
class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver" />
</list>
</property>
<!--
| Whereas CredentialsToPrincipalResolvers identify who it is some Credentials might authenticate,
| AuthenticationHandlers actually authenticate credentials. Here we declare the AuthenticationHandlers that
| authenticate the Principals that the CredentialsToPrincipalResolvers identified. CAS will try these handlers in turn
| until it finds one that both supports the Credentials presented and succeeds in authenticating.
+-->
<property name="authenticationHandlers">
<list>
<!--
| This is the authentication handler that authenticates services by means of callback via SSL, thereby validating
| a server side SSL certificate.
+-->
<!--
| This is the authentication handler declaration that every CAS deployer will need to change before deploying CAS
| into production. The default SimpleTestUsernamePasswordAuthenticationHandler authenticates UsernamePasswordCredentials
| where the username equals the password. You will need to replace this with an AuthenticationHandler that implements your
| local authentication strategy. You might accomplish this by coding a new such handler and declaring
| edu.someschool.its.cas.MySpecialHandler here, or you might use one of the handlers provided in the adaptors modules.
+-->
<bean class="my.project.cas.authentication.handler.CnsAuthHandler" />
<!-- lppe-->
<ref bean="lppeEnabledLdapAuthenticationHandler" />
</list>
</property>
</bean>
<!-- datasource di connessione a db mysql -->
<!-- context di connessione a ldap-->
<!--
This bean defines the security roles for the Services Management application. Simple deployments can use the in-memory version.
More robust deployments will want to use another option, such as the Jdbc version.
The name of this should remain "userDetailsService" in order for Spring Security to find it.
-->
<!-- <sec:user name="##THIS SHOULD BE REPLACED##" password="notused" authorities="ROLE_ADMIN" />-->
<!-- questa direttiva permette staticamente di assegnare all'utente dariush.behboudi (pescato nel nostro caso da ldap di vedersi assegnato il ruolo di ROLE_ADMIN,
necessaio per loggarsi nel services management console-->
<sec:user-service id="userDetailsService">
<sec:user name="cas.sa" password="notuseed" authorities="ROLE_ADMIN" />
</sec:user-service>
<!--
Bean that defines the attributes that a service may return. This example uses the Stub/Mock version. A real implementation
may go against a database or LDAP server. The id should remain "attributeRepository" though.
-->
dell'utente-->
<bean id="attributeRepository" class="org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao">
<property name="baseDN" value="%MYBASEDN%"/>
<property name="contextSource" ref="contextSource" />
<property name="requireAllQueryAttributes" value="true"/>
<property name="queryAttributeMapping">
<map>
<entry key="username" value="cn" />
</map>
</property>
<property name="resultAttributeMapping">
<map>
<entry key="cn" value="cn" />
<entry key="sn" value="sn" />
<entry key="cnscartareale" value="cnscartareale" />
<entry key="mail" value="mail" />
<entry key="cns" value="cns" />
<entry key="cnssubject" value="cnssubject" />
<entry key="idpcrluserid" value="idpcrluserid" />
<entry key="tipocertificato" value="tipocertificato" />
<entry key="cnsisuser" value="cnsisuser" />
<entry key="pwdChangedTime" value="pwdChangedTime"/>
</map>
</property>
</bean>
<bean id="serviceRegistryDao" class="org.jasig.cas.services.JpaServiceRegistryDaoImpl"
p:entityManagerFactory-ref="entityManagerFactory" />
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="true"/>
<property name="showSql" value="true" />
</bean>
</property>
<property name="jpaProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>
<prop key="hibernate.hbm2ddl.auto">update</prop>
</props>
</property>
</bean>
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory"/>
</bean>
<tx:annotation-driven transaction-manager="transactionManager"/>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName">
<value>com.mysql.jdbc.Driver</value>
</property>
<property name="url">
<value>jdbc:mysql://127.0.0.1:3306/cas_db</value>
</property>
<property name="username">
<value>DBUSERNAME</value>
</property>
<property name="password">
<value>DBPASSWORD</value>
</property>
</bean>
<bean id="auditTrailManager" class="com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager" />
<bean id="healthCheckMonitor" class="org.jasig.cas.monitor.HealthCheckMonitor">
<property name="monitors">
<list>
<bean class="org.jasig.cas.monitor.MemoryMonitor"
p:freeMemoryWarnThreshold="10" />
<!--
NOTE
The following ticket registries support SessionMonitor:
* DefaultTicketRegistry
* JpaTicketRegistry
Remove this monitor if you use an unsupported registry.
-->
<bean class="org.jasig.cas.monitor.SessionMonitor"
p:ticketRegistry-ref="ticketRegistry"
p:serviceTicketCountWarnThreshold="5000"
p:sessionCountWarnThreshold="100000" />
</list>
</property>
</bean>
</beans>
Thank you very much.
We have decided to use Ping Federate to be our SSO solution. I have searched many examples but have not found a spring configuration that clearly describes how I need to set up my SP and/or IdP on the PingFederate side. I have not found a Spring document that describes what I need exactly to implement this.
Any help, much appreciated.
Currently there's no step-by-step guide on establishing federation between Spring SAML and Ping, but the steps are very similar to what's described in the quick start guide of Spring SAML.
The best approach is to start with the sample application included inside Spring SAML, configure it to work with Ping and then transfer the configuration to your current Spring application.
The high level steps are:
deploy Spring SAML sample application
download its SP metadata from https://server:port/context/saml/metadata (just open browser to the URL and store all content it returns)
configure Ping by creating new "SP Connection", as part of the process you import metadata which you stored earlier, to start with you can use defaults on most of the settings
when done, export the IDP metadata from Ping using Administrative functions -> Metadata Export for the connection you created in the previous step
import the IDP metadata to your Spring SAML (examples are in the manual)
This establishes federation between the two and enables you to start authenticating your users through Ping.
The metadata configuration (bean metadata) should look as follows in your case:
<bean id="metadata" class="org.springframework.security.saml.metadata.CachingMetadataManager">
<constructor-arg>
<list>
<bean class="org.springframework.security.saml.metadata.ExtendedMetadataDelegate">
<constructor-arg>
<bean class="org.opensaml.saml2.metadata.provider.FilesystemMetadataProvider">
<constructor-arg>
<value type="java.io.File">classpath:security/idp.xml</value>
</constructor-arg>
<property name="parserPool" ref="parserPool"/>
</bean>
</constructor-arg>
<constructor-arg>
<bean class="org.springframework.security.saml.metadata.ExtendedMetadata"/>
</constructor-arg>
<property name="metadataTrustCheck" value="false"/>
</bean>
</list>
</constructor-arg>
</bean>
Make sure to replace resources/security/idp.xml with metadata from PF. You can remove all unused instances of ExtendedMetadata beans (like the one for SSO Circle). The reason metadata bean can contain multiple "links" is that it can support many IDPs at the same time.
I use restlet in camel route in from("restlet:http/myLink") clause. When user's requests more then ten per second, I begin recieve errors processing request like a "org.restlet.engine.connector.Controller run
INFO: Connector overload detected. Stop accepting new work"
I think, that error is caused by number of threads,request query's size or number,or something like that. I try set to maxThreads param different values in spring config
<bean id="restlet" class="org.apache.camel.component.restlet.RestletComponent">
<property name="maxThreads" value="15"/>
</bean>
but I am not succeed. In documentation http://camel.apache.org/restlet.html I ddin't find ant param for setting size\number of request queue. I need help :(
P.S. camel-restlet version is 2.12.2
Update
I try to set big numbers to maxThreads,maxConnectionsPerHost,maxTotalConnections, but it's useless. If inject org.restlet.Component to camel's config like that:
<bean id="restletComponent" class="org.restlet.Component" />
<bean id="restlet" class="org.apache.camel.component.restlet.RestletComponent">
<constructor-arg index="0">
<ref bean="restletComponent" />
</constructor-arg>
<property name="maxThreads" value="255"/>
<property name="maxConnectionsPerHost" value="1000"/>
<property name="maxTotalConnections" value="1000" />
</bean>
How I can override properties, that use BaseHelper params?
After go through the options of lowThread as well.
But I found current released camel doesn't support it.
I am working on a Spring WebFlow project which has a lot of property values in XML files, as any Spring programmer knows. I have database user names, password, URLs, etc.
We are using Eclipse with Spring WebFlow and Maven. We are trying to have an SA do the builds but the SA does not want to go into the XML files to change the values, but on the other hand, we don't know the production values. How do we work with this?
Most SA are more willing and confident to deal with .properties file rather than .xml.
Spring provide PropertyPlaceholderConfigurer to let you define everything into one or several .properties file and substitute the placeholder in applicationContext.xml.
Create a app.properties under src/main/resources/ folder:
... ...
# Dadabase connection settings:
jdbc.driverClassName=org.postgresql.Driver
jdbc.url=jdbc:postgresql://localhost:5432/app_db
jdbc.username=app_admin
jdbc.password=password
... ...
And use PropertyPlaceholderConfigurer in applicationContext.xml like so:
... ...
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<value>app.properties</value>
</property>
</bean>
... ...
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="${jdbc.driverClassName}" />
<property name="url" value="${jdbc.url}" />
<property name="username" value="${jdbc.username}" />
<property name="password" value="${jdbc.password}" />
</bean>
Check out Spring PropertyPlaceholderConfigurer Example for more details.
In addition, from application deployment perspective, we usually package app in some executable format and the .properties files are usually packed inside the executable war or ear file. A simple solution is to configure your PropertyPlaceholderConfigurer bean to resolve properties from multiple location in a pre-defined order, so in the deployment environment, you can use a fixed location or environment variable to specify the properties file, also note that in order to simplify the deploy/configure task for SA, we usually use a single external .properties file define all runtime configuration, like so:
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<!-- Default location inside war file -->
<value>classpath:app.properties</value>
<!-- Environment specific location, a fixed path on server -->
<value>file:///opt/my-app/conf/app.properties</value>
</list>
</property>
<property name="ignoreResourceNotFound" value="true"/>
</bean>
Hope this helps.
Another simple way is Spring Expression Language (SpEL)
for example
<property name="url" value="#{ systemProperties['jdbc.url'] }" />
Documentation
spring documentations
Also you can define a propertyConfigurer programmatically in configuration class:
#Configuration
#PropertySource("classpath:application.properties")
public class PropertiesConfiguration {
#Bean
public PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer(Environment env) {
PropertySourcesPlaceholderConfigurer configurer = new PropertySourcesPlaceholderConfigurer();
configurer.setEnvironment(env);
return configurer;
}
}