I'm developing a java Security Token Service using the Metro framework in NetBeans 8.0 following this tutorial: https://metro.java.net/2.0.1/guide/Building_custom_STS_.html
I've implemented the STSAttributeProvider interface to provide custom attributes and build up the <AttributeStatement>. In the same manner I would like to add an <AuthenticationStatement> block in the SAML response but I can't seem to find out how to do this. What would be the correct approach?
Thanks!
Related
I'm new with sso login (ADSF - SAML2) with Umbraco v8 and I need some help to know if this is the right package for me.
I'm working on a website using Umbraco CMS v8 and I need to create a custom members login (frontend) using the sso authentication of my company (ADFS - no Azure AD) and my custom login form (C# and .Net Framework 4.7.2+).
I found on NuGet the "itfoxtec-identity-saml2" package that can be used to do it and I saw that there are two packages that could help me: "ITfoxtec.Identity.Saml2" and "ITfoxtec.Identity.Saml2.Mvc"
What are the difference and what reccomand to use?
Any other suggestions to create an SSO Members Login in Umbraco v8, is welcome.
Thank you and I look forward to your reply
Adriano
The ITfoxtec.Identity.Saml2 is the base component implementing the actually SAML 2.0 standard.
The ITfoxtec.Identity.Saml2.Mvc and ITfoxtec.Identity.Saml2.MvcCore implements the elements needed to integration with ASP.NET MVC. The ITfoxtec.Identity.Saml2.Mvc component is for .NET Framework and the ITfoxtec.Identity.Saml2.MvcCore component is for .NET Core and .NET 5.0.
I'm afraid that i do not know anything about Umbraco, sorry I cannot help you there.
I followed official documentation from : https://docs.wso2.com/display/IS541/Integrating+WSO2+Identity+Server+with+Liferay to Login in my Liferay Portal with wso2is user, but it not work for me in wso2is-5.4.1 and liferay6.2ga6. When I try login, liferay's log print "Primary URL :https://wso2is.local:9443/services/Secondary URL :null" but no call to wso2is server is done.
I added this lines into my portal-ext.properties :
auth.pipeline.pre=org.wso2.liferay.is.authenticator.WSO2ISAuthenticator auth.pipeline.enable.liferay.check=false wso2is.auth.service.endpoint.primary=https://wso2is.local:9443/services/ wso2is.auth.thrift.endpoint=localhost wso2is.auth.thrift.port=10500 wso2is.auth.thrift.connection.timeout=10000 wso2is.auth.thrift.admin.user=admin wso2is.auth.thrift.admin.user.password=admin wso2is.auth.thrift.endpoint.login=https://wso2is.local:9443/ wso2is.auth.thrift.system.trusstore=/wso2is-5.4.1/repository/resources/security/wso2carbon.jks wso2is.auth.thrift.system.trusstore.password=wso2carbon
Is there something wrong?
Unfortunately, a lot of the WSO2 documentation is very crufty, containing articles that have been pulled forward from previous versions of the documentation without regression testing on the use cases they present. In short, there's stuff in the documentation that plain doesn't work. If you look at the bottom of the article you'll see the following:
Please note that the above configuration is tested with Liferay 6.1.1
and WSO2 Identity 3.2.3/4.0.0.
I recall I tested this a long time ago, and determined that it wouldn't work with the current version, but that was so long ago that I can't remember why. In any case, the approach presented for integrating Liferay was offered at a time where Liferay didn't have the ability to use standardized authentication protocols like SAML. Now that it does, you probably want to do it in a standards compliant manner instead of using an authentication interface Liferay only promotes using for proprietary authentication systems.
My suggestion is that if you are using Liferay portal enterprise with LDAP that you use the built-in SAML connector. If you aren't using Enterprise, there are some compatible authenticator extensions in the extensions store that will also integrate with Liferay. If you configure Liferay to be a client against WSO2 and then integrate Liferay to LDAP on the backend, it also allows Liferay to be used as a user dashboard instead of the jaggery based one that comes in the product.
this is newbie question about identityServer and windows authentication. The samples provided with IdentityServer3 with windows authentication seem to implement it using WSFederation, like the one provided in this link https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/WebHost%20(Windows%20Auth%20All-in-One).
The newest samples with identityserver4 are using a different approach without Federation. Are these approaches equivalent? Are there benefits in one approach over the other.I can understand using Federation for ADFS, but not for Windows authentication with AD. I know I am missing something can't figure it out. What is it? Thanks.
Identity Server 4 is based on .NET Core which currently does not support WS-Federation so if that is a requirement you should stick to Identity Server 3 on the "standard" framework.
According to the devs there's a "test" version out for WS-Fed but if it will be included in the final release of .NET Core 2.0 is still uncertain.
See https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500
We are trying to design a Single Sign On using SAML implementation. Our application uses JBOSS 4.3 server. Based on research JBOSS 4.3 does not support SAML standards. Anyone who has same experienced? What alternative can we used for this scenario.
We are considering spring-ws as the platform for implementing web services that will be deployed on weblogic. We need to use WS-Security with SAML tokens issued by our identity management platform (TFIM).
The Spring-ws documentation for XwsSecurityInterceptor does not mention SAML, and it is not clear to me if would work in this context.
I guess alternatives could be to do our own interceptor which uses OpenSAML or somehow utilises the SAML support in weblogic.
Does anyone have experience with this? Would be nice to aim for a solution that is known to be workable.
Apache WSS4J does support SAML tokens, and Spring-WS comes with a Wss4jSecurityInterceptor, so I'd guess you could get it working out of the box.