I am using spring security's open saml library for authentication.
My Service Provider is my spring web application configured with spring saml.
My IDP is OpenSSO.
In the spring-security-saml2-core library, the JKSKeyManager is never called, but the KeyManager gets called.
So is the library using the .jks keystore file as its keys or the 'apollo/nalle123' as its keys? what's their difference?
The org.springframework.security.saml.key.KeyManager is an interface, org.springframework.security.saml.key.JKSKeyManager is its implementation. So if you see calls to KeyManager, in default configuration it means they're hitting the JKSKeyManager.
The apollo/nalle123 key is stored inside the .jks file (samlKeystore.jks in the sample application), configured to be used by the KeyManager. Apollo is alias of the key in the .jks file, nalle123 is its password.
Spring SAML combines usage of keys provided in the KeyManager and keys supplied in SAML metadata.
Related
I have implemented an authorization server (spring boot application) using the spring security framework. In the application startup, the RSA key pair is generated and the Json Web Key Set (jwks) is also initialized with a public key. This public key is shared through an endpoint to decrypt the token in the resource server.
Now when the authorization server will be deployed in the multiple nodes, there will be multiple jwks initialized and will cause an issue to identify the appropriate public key from the multiple token stores.
What is the best practice to handle such architecture?
I have been working with SAML IDP implementation using saml_idp gem in Ruby.
My user-management is already acting as IDP for a ServiceProvider. All the configuration is totally set for that Service Provider alone. Now, I want to support one more Service Provider where the configuration is different from the existing one.
The question is how would I support multiple SP with different signatures, certificates in IDP to act separately for different service providers.
I have saml_idp_initializer.rb in my project. As mentioned earlier, it is more specific to a SP.
I found a workaround solution where I can set up the SAML IDP configuration in the runtime which solves serving the requests to SP by the new IDP configuration.
I am trying to enable OIDC authN and authZ workflow for my spring-java-web application. Ideally I wanted to do it in a IDP agnostic way.i.e.This application could be integrated with only and any one of the Azure AD,OKTA,AWS SSO,Google-auth by deployment admin.And I want users to be redirected to whatever provider the application is integrated with.
With OIDC as a standard, my understanding is i should be able to write a OIDC auth processing filter that should work with any of the providers. The necessary config that varies per provider ( auth url,client id,secret,JWKS url to get the provider keys etc) will be passed to this filter/rest template as parameters.
Q.1 Is it possible to implement provider agnostic OIDC filter? Can someone give any pointers?
I am aware that Spring natively provides Oauth2 libraries/apis like AuthorizationCodeResourceDetails, OAuth2ClientAuthenticationProcessingFilter . However I do not see any OIDC native processing filter in built. Is there any?
I tried and understood the workflow as given in https://www.baeldung.com/spring-security-openid-connect .However when i try to tweak this code to make it work with Azure AD it fails. Thats because Azure AD requires
The response_type parameter must include id_token.
The request must include nonce parameter to be set in request.
AuthorizationCodeResourceDetails does not support such param. Given that OIDC is a common standard ,
Q-2. I fail to understand why every provider still has different requirements? Doesn't it defeat the purpose of OIDC . Infact I read that google throws error if you pass nonce
Q-3. Are there any spring native ways to configure these additional provider specific params like nonce , promt, additional response-type ,preferable with examples?
I think your problems with Spring Security OIDC are that you're using the legacy OAuth library (at least that's what the baeldung article is illustrating). OAuth2 and OIDC are part of Spring Security 5.x now and not a separate project. There's an OIDC client "login-client" in this example: https://github.com/jgrandja/oauth2-protocol-patterns that might show different. Yes, OIDC should allow you to swap providers in and out although not all OIDC providers will implement everything (e.g. discovery, etc.)
Hello Spring Security SAML pros and enthusiasts alike,
For instance, Service Provider metadata generation yields something like
<md:AssertionConsumerService Location="http://localhost:8080/<app-servlet-context>/saml/SSO"/>
when deployed and running on local Tomcat container, which can be used by Identity Management to configuration SAML Consumer URL.
We're using Okta and OneLogin to test. Everyone's happy.
Issue I'm facing is that same web application configuration deployed on to docker container preconfigured with specific DNS record returns
<md:AssertionConsumerService Location="http://<app-context-root>:8080/<app-servlet-context>/saml/SSO"/>
replacing localhost with application context root (default?).
Actual domain http://<app-name>.<company-domain>.com is nowhere to be found, rendering Assertion Consumer Service Location value unusable for purpose of configuring IdP-initiated SSO.
Same case for Single Logout Service Location value.
Can someone help me understand this behavior and configure my implementation so Location for both AssertionConsumerService and SingleLogoutService provided in Service Provider Metadata looks like
<md:AssertionConsumerService Location="http://<my-app-dns-domain-name>:8080/<app-servlet-context>/saml/SSO"/>
<md:SingleLogoutService Location="http://<my-app-dns-domain-name>:8080/<app-servlet-context>/saml/SingleLogout"/>
Thank you!
How did you generate your metadata ? Did you do it programmatically ?
If yes you can use the method setEntityBaseURL() of MetadataGenerator class.
I'd like to implement a Single Sign-on (SSO) authentication layer in my Spring-based application with the aim of supporting authentication and authorization from different security domains.
I've chosen Shibboleth as IdP, but I have yet to identify what I will use for the SP.
The choices are:
Spring Security SAML Extension: component enables both new and existing applications to act as a Service Provider in federations based on SAML 2.0 protocol and enable Web Single Sign-On. Spring Security Extension allows seamless combination of SAML 2.0 and other authentication and federation mechanisms in a single application. All products supporting SAML 2.0 in Identity Provider mode (e.g. ADFS 2.0, Shibboleth, OpenAM/OpenSSO, RM5 IdM or Ping Federate) can be used to connect with Spring Security SAML Extension.
Shibboleth (also as SP): Shibboleth is a web-based technology that implements the HTTP/POST, artifact, and attribute push profiles of SAML, including both Identity Provider (IdP) and Service Provider (SP) components.
So, I've some questions:
Is it a good idea to use directly Spring SAML as SP in terms of
scalability and maintainability?
It is possible to use an external SP together with Spring Security? How have I to configure my application and/or my application sever (JBoss 8.0 - WildFly)?
Where do I define the roles (for each scenario)?
Which is the worthwhile choice?
Best regards, V.
The main difference between the two is deployment scenario:
Shibboleth SP plugins are deployed directly to the Apache/IIS web server.
Spring SAML is embedded in your application.
Both have pros and cons.
Is it a good idea to use directly Spring SAML as SP in terms of scalability and maintainability?
Spring SAML
Offers great control over how authentication is performed and how the authentication process interacts with your application. You can e.g. create your own configuration UIs and dynamically add IDPs, create custom login screens as part of your application, have complete and easy control over error handling, easily support multiple IDPs, dynamically configured details of the SSO (requested AuthnContexts, NameIDs, bindings, authentication forcing).
Easily parse received SAML attributes in various formats, support multiple authentication methods in the same application.
Dynamically generate SP metadata, it provides limited multi-tenancy and supports profiles not available in all other options (e.g. Single Logout, Holder of Key, IDP Discovery).
Seamlessly interacts with Spring Security which brings a set of benefits of its own. With Spring SAML you can also configure complete authentication and authorization policy directly in your application (e.g. which pages require authentication or not and when, role based access control to content, authentication step-up on dynamic conditions, ...).
Allows you to deploy the application on any application server or container and behind any reverse proxy or web server with no affect on functionality.
Shibboleth plugins
These are statically configured and typically interact with your application through HTTP headers. They decouple authentication logic from the application itself, so the only thing you need to take care of is acceptance of the headers and initialization of your application session with correct security context. The definition of which pages are secured is present on the IIS/Apache server and based on URL patterns which means that authentication and authorization policy is partly defined outside of your application.
You need to make sure that the application can only be accessed through the web server (= prohibit all direct access) as that would allow forging of the headers.
Doesn't require many changes to the application itself and can therefore typically be easily used with legacy systems.
It is possible to use an external SP together with Spring Security? How have I to configure my application and/or my application sever
(JBoss 8.0 - WildFly)?
Yes, it is possible, but it will require effort. You could e.g. configure WildFly to set a shared domain cookie in encrypted format and verify the cookie in your Spring Security configuration.
Where do I define the roles (for each scenario)?
With Spring SAML you define roles when processing the SAML Response by e.g. parsing of the SAML attributes. This is done by implementing SAMLUserDetailsService interface and plugging in to the samlAuthenticationProvider.
With Shibboleth you can forward attributes received from IDP to your application with headers and parse them in your application.
WildFly (probably) allows you to define security context and roles directly in SP with no need to configure this in your application. Such configuration might not be portable across application servers.
Which is the worthwhile choice?
All options will enable you to perform WebSSO with SAML 2.0. People typically choose based on their requirements (e.g. customization needs), environment (used web server, application server), preferred development methodology (Java, .NET, other), used frameworks, legacy code. Both Spring SAML and Shibboleth plugins are used by many customers.