I am integrating spring-security-saml extension to support SSO in my web-application, my application should allow different customers to add their IDP metadata and their certificate to my webapp (which is an SP) so that my webapp can initiate SSO against their idp.
Right now I am defining a "metadata" bean in my java config where in I add the idp metadata to CachingMetadataManager. But this happens only once, I am not able to figure out how do I add a new idp metadata to MetadataManager at runtime (without re-starting my app). Can I just get the metadata bean from spring ApplicationContext and add a new provider to it? Will it work?
What is the general practice to support the above use case (adding new idp's at runtime) with spring-SAML? are there any other java libraries which support this.
Thanks in advance
The CachingMetadataManager is synchronized and you can add/remove MetadataProviders during runtime by getting the bean from the application context and calling addMetadataProvider/removeMetadataProvider.
Related
I built a claims-aware asp.net mvc application following the steps outlined in this page: https://learn.microsoft.com/en-us/dotnet/framework/security/how-to-build-claims-aware-aspnet-mvc-web-app-using-wif. The example in the page uses an STS on the local host, but in my application I am pointing to a fully-functioning AD FS on a different server.
I'm using Framework 4.7 and Windows Server 2016 to host the AD FS and to host the web application.
After I deployed the application I ran the Windows Identity Federation Utility against it (because I thought I needed it to add the application as a Relying Party Trust on the AD FS). This utility inserts a lot of tags into the web.config that refer to the Microsoft.IdentityModel namespace.
I then added the application as a Relying Party Trust to the AD FS, and navigated to the claims-aware app. The page failed because the sample code cast the claim returned by the STS as System.Security.Claims.Claim. When I changed it to cast as Microsoft.IdentityModel.Claims.Claim it worked fine.
The example I was following makes no mention of the Windows Identity Federation Utility. Do I need to use that? Or would this have worked without it?
When I try reversing the web.config changes that the utility inserted the site fails with a 401 error (access denied due to invalid credentials) so obviously the stuff inserted by the Utility is needed to get authentication from AD FS. Is this because I ran the Utility on the web site before adding it as a relying party trust to the ADFS?
The answer here is: don't run the Windows Identity Federation Utility if you are using ADFS Server 2016, as it forces use of the Microsoft.Identity libraries, which are deprecated. I mistakenly thought this utility was needed to create the FederationMetadata.xml file.
I created the FederationMetadata.xml file manually and reverted my web.config back to what it was before I ran the utility. This reverted me back to using the System.Identity libraries, which were added to the 4.5 framework, instead of the now-deprecated Microsoft.Identity libraries.
Just to note that the more "modern way" is to use the OWIN WS-Federation library.
This example is for Azure AD but you simply point to the metadata and the code figures all the rest out for itself.
I am upgrading a resource server that accepts access tokens from our oAuth server. In .NET 4.7, I had a startup configuration that looked like this:
appBuilder.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions());
When I add the Nuget Package 'Microsoft.Owin.Security.OAuth', I get a warning that the package is not compatable with the target .NETCoreApp. Makes sense, but I'm not sure what the new package is.
I thought the package I needed was 'Microsoft.AspNetCore.Authentication.OAuth'. That allows me to add to startup:
services
.AddAuthentication(OAuthDefaults.DisplayName)
.AddOAuth("Bearer", options => options.AuthorizationEndpoint = "uhhh" );
Why would I be configuring an endpoint, I just want to look for an authorization token, not actually serve them up. This looks like the setup for an oAuth server, not a recipient. Also, the old 'OAuthBearerAuthenticationOptions' class allowed me to override things like 'AccessTokenFormat' but I'm not seeing that in the new options.
Lastly, I see that there is the option to configure oauth this way:
app.UseOAuthAuthentication
But it complains that it's Obsolete, looks like a Core 1 version of 'AddOAuth', and nothing about AccessTokenFormat.
Any ideas?
Core does not provide a direct replacement for those APIs or their associated token server. The current guidance is that you use a server like IdentityServer4 along with AddJwtBearerAuthentication.
I've followed the steps on http://www.cloudidentity.com/blog/2014/02/12/use-the-on-premises-organizational-authentication-option-adfs-with-asp-net-in-visual-studio-2013/ to create a new MVC application using ADFS to authenticate my users. Now the team behind the ADFS configuration needs the application metadata file to allow the application to connect the ADFS.
How can I generate this metadata file?
It normally "lives" at /FederationMetadata/2007-06/FederationMetadata.xml in your STS website. If you used a standard solution like thinktecture then that is the case. Otherwise, you can generate it yourself using the .Net classes in System.IdentityModel.Metadata. You can find some inspiration at https://github.com/IdentityServer/IdentityServer3.WsFederation/blob/25a2101f9bfe78e4ec856eb15c9bf19a9a9b256c/source/WsFederationPlugin/WsFederationController.cs and related classes.
To write custom federation , after generating jar using pom from wso2 docs , i put that in said folder . but how do use this custom federation , Documentation stops after this .
I cant see my new custom federation name in any drop down , i was expecting to see this in the list of federation drop down in Service Provider configuration
If we write custom federation for Oauth IDP , all the urls configuration have to be programatically managed in OSGI bundle, we wont get UI for that ?
Why is OAuth not supported if we have any other vendor apart from facebook and google, yahoo, which is not openid connect we cant use any out of the box SSO .
i got my Bundle loaded on to WSO2 these were the steps
i started wso2 with osgi console
$>wso2Server.bat -DosgiConsole
After this server starts and if we hit enter we can get osgi prompt
there we can type osgi commands
try $> package org.abc.whateverpackage
this will list all the bundles that import/export the given package name within the runtime.
try to $install file:<filepath> this gives an error message saying something is missing in imnport or whatever issue might be
im my case i started with pom from wso2 so i had to correct the configuration
from org.wso2.carbon.identity.application.authentication.framework.*,
to org.wso2.carbon.identity.application.authentication.framework.*;version="4.2.2"
the number 4.2.2 i got from the dependencies in the pom
i added BundleActivator
<Bundle-Activator>com.osgi.customauth.Activator</Bundle-Activator>
Now when i create an IDP i can see my custom Authenticator in the list along with google , yahoo etc
But all the urls for OAUTH are in my code i have to programatically externalize this , i did not yet find a clean way to do this
My small Web API project (hosted via SelfHostHttpServer) has a few dependencies I want to inject into the controllers. In order to do this, I have implemented IDependencyResolver and called httpConfig.ServiceResolver.SetResolver.
This would work fine, except it seems I need to satisfy the internal dependencies the Web API requires. The first time I ran it, I saw that it needed to resolve the controller factory, so I added an instance of DefaultHttpControllerFactory to my container. Now every damn time I refresh the page, it crashes with the next unresolved dependency the framework is trying to resolve.
Am I going about this the wrong way, or am I really supposed to try and guess all of the default implementations and be forced through this crash-fix-refresh cycle of discovering what dependencies are required for the Web API framework to work correctly?
What your resolver is doing in case it can't resolve the dependency? The proper behaviour should be returning null. ASP.NET Web API DependencyResolver (httpConfig.ServiceResolver) is internally using two resolvers:
The one you set through SetResolver (user rosolver)
The built in DefaultServiceResolver
If user resolver returns null for dependency then Web API falls back to DefaultServiceResolver which can handle all built-in dependencies.