In the page attribute contract we are having a field called subject name format, but here there are so many formats as follow,
• urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
• urn:oasis:names:tc:SAML:1.1:nameid-format:emailaddress
• urn:oasis:names:tc:SAML:1.1:nameid-format:X509subjectname
• urn:oasis:names:tc:SAML:1.1:nameid-format:Windows Domain Qualified name
• urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos
• urn:oasis:names:tc:SAML:1.1:nameid-format:entity
could you guys please explain me why and where these name formats are being used.
This isn't a PingFederate thing - it's really all of SAML. The definitions are in SAML-Core in Section 8.3. Most commonly, people use "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" as it allows for "free-form" adherence. You and your partner agree on a format, and just do it. The others add validation rules to the formatting of the SAML Subject.
To follow up on the response provided by Andrew, most Service Provider (SP) websites hosted on the internet rarely ever require a specific value for the subject name format. Out of the many integrations with PingFederate and hosted SaaS applications configured, I haven't encountered a case where the format was required to be anything other than "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified".
Related
We are an ISV building an enterprise SaaS product.
We would like to enable our customers define their IDP SAML configuration.
We are a startup and would like to support SAML as lean as possible.
1. What is the minimal configuration needed to support the major IDPs?
After reading Okta's article I understand that:
Certificate
IDP Sign-in URL
Are a must.
Say that we use a single ACS endpoint (We will implement our own logic by looking at the SAML assertion)
Is there anything else mandatory?
What about bindings? Do all major IDPs support HTTP redirect?
2. What is needed to be defined on the IDP side?
We tend to use the HTTP redirect binding, should it work with most IDPs? Is a metadata endpoint important?
As for "what is required": in many cases, you will have to generate so called "metadata.xml" file to provide the information to the vendor, so they might install a testing environment for you.
I've implemented about 5 SAML integrations with different vendors so far. The truth is that not all of them require full-fledged SAML 2.0 standard, but some of them do. I think my article should be also helpful to you https://dev.to/optiklab/working-example-of-saml-single-sign-on-integration-using-c-39mb and my open sourced SAML integration project (https://github.com/optiklab/SAML-integration-utilities) contains both Metadata File generator and C# examples for forming both SAML response and assertions. They proved to be working with many vendors, like Ping Identity, etc.
Let me know if you have more specific questions.
Last week, we received information that the user-agent has its days counted.
Google announced that it will get rid of the User-Agent String in Chrome and Mozilla/Microsoft support the idea.
I'm wondering what will be the impact on that for GXT specific code, and how will we be able to build, and later, how the loading script may choose which permutation to use.
Any thoughts on that?
https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/-2JIRNMWJ7s/yHe4tQNLCgAJ
Actually, it seems that Chrome team plans to "freeze" UA string, while at the same time they would be providing an alternative mechanism to getting UA information using UA Client Hints. GWT could still operate with "frozen" UA string, or could be extended to use new API to get exact information on supported features by particular client browser.
SAML 2.0?
OpenId?
OAuth 2.0?
CAS?
And others?
I know they all can do SSO, but I want to find out what are all standard protocol nowadays we used for SSO that covers 80% of market?
Anyone knows how do I find the result?
There is no standard protocol because it depends on the use case e.g.
Microsoft Enterprise uses WS-Fed.
Java Enterprise uses SAML-P.
Native (mobile) uses OAuth2 for consent. If you want authentication on top of this, add OpenID Connect.
And it also depends on the STS - not every STS supports all the above.
WSO2 EMM looks like a very interesting effort. I am looking for OMA-DM and optionally TR-069 client support as well. In other words, the ability of a device with an OMA-DM client to enroll and be managed by WSO2 EMM. One might say that what want is an OMA-DM server, but in fact, I am looking for a server that can address both mobile device (smartphone/tablet) as well as "other" device management options.
Thank you in advance!
WSO2 EMM doesn't support OMA-DM or TR-069 client support (yet). As a core developer involved in the project I would certainly raise these protocols as important features to address in the future releases.
From WSO2 EMM right now what we have tried (please note that I am a core team member) to address is the management of mobile platforms which are popular these days. For this we have dealt with the MDM APIs provided by the platforms. For this its not necessary to dig into the implementation details of MDM protocol under each platform since its upto the MDM vendor to provide and implement it.
Note: As far as I know Windows supports OMA-DM. Anyway in a future release there will be Windows phone support.
To add additionally to your point, if you think it from a different angel its also possible to integrate OMA-DM clients. For this the implementation of the EMM needs to be done adhering to the server aspect of the protocol. Yes this is perfectly possible and if there are real use cases or need we might go for it.
I am looking into options for implementing single sign-on (by which I mean a single set of user credentials authenticating against a single, shared, identity store) across a range of websites.
All of the websites nominally belong the same organisation (and so we can assume a trusted relationship between them), but are hosted on different domains, and span different technologies - inc. .NET, Java and PHP.
We are consolidating all user profiles into a single back-end CRM system, and need some way to provide robust access to this for all current (and future) web properties.
We have a nascent SAML provider running, and the default option is to extend access to this across all the (currently) unsupported properties. Is this the best option? All the online references to SSO products (CAS, CoSign etc.) seem to be very old (2004+).
Have a look at Microsoft's ADFS v2.0 which support .NET
There are commercial products that do this e.g. PingIdentity, and open source ones e.g. OpenAM.
These products all support SAML.
For Java, put something like OpenAM in front of it or use the OpenSSO / OpenAM fedlet.
For PHP, use simpleSAMLphp.
The keyword to use to get current references would be something "SAML federation".
Refer SAML-based products and services
Use of the SAML protocol here makes a ton of sense. It could even allow you to federate with cloud-based services if/when your company decides to go that direction.
SAML does not require the target servers (aka "service providers" or "relying parties" in MS parlance) to be referenced using a fully qualified domain name with a common DNS root. It is also technology agnostic so it really doesn't matter what HTTP stack the service provider is running.
I'm not sure what interfaces are available to your back-end CRM system, but LDAP or SQL connections are typically used to get identity claim information and build the SAML response.
A few Identity Provider products you may want to research include Microsoft ADFS, PortalGuard (for whom I work) and Ping.