The Security Assertion Markup Language is a protocol that facilitates the secure exchange of authentication and authorization information between partners regardless of their security systems or e-commerce platforms. In this article, David Whitehurst explains how SAML might be used in a single-sign on product, and issues a call for arms for a SAML server solution.
Read A Proposal for SAML communications with JAAS
Could not access docs. The response from the server was:
You don't have permission to access /security/saml/v2.0/ on this server.
Could not access docs. The response from the server was:ForbiddenYou don't have permission to access /security/saml/v2.0/ on this server.
I still cannot access http://docs.oasis-open.org/security/saml/v2.0/
and getting the same error.
The whole of http://docs.oasis-open.org/
is inaccesible and shows a blank page.
Any help would be greatly appreciated.
An implementation of the SAML Server mentioned is already in the wild. The UK Higher Education JISC funded Guanxi project
provides such an implementation, making use of the Shibboleth SAML profile.
SAML and it's many profiles/implementations allow you to construct SSO services where a user can login to their own Identity Provider (IdP) first and then wander through a federation, accessing resources without having to login again.
In fact, the UK's Joint Information Systems Committee (JISC)
has decided to use the open source Shibboleth profile of SAML for institutional SSO. It's this profile that the Guanxi project is implementing, alongside the implementation from the United StatesGuanxi news
oops, forgot to mention that the open source Bodington Virtual Learning Environment
(VLE) has an embedded Guanxi Identity Provider (IdP) which is in effect a SAML Server
I like the point that you start looking for security that will extend current security to the next generation of web architectures, which are services based and loosely coupled. However, you talk about SAML servers and JAAS as if this is all to consider. Note that application security is more than single problem to solve and that we do have enoughh fragmented security solutions tha require professioneals to bring them together to something that works reliable.
I have three comments to make:
1. Reading your article, I couldn't really see the difference between your proposed solution and a JAAS Login Module that uses teh SAML token for authentication. Each web application would be configured with this LoginModule and check for the SAML token. If its not there, it would try and access the SAML server for authentication. Maybe I miss your innovation here, but a servloet based approach doesn't look good to me (see my 2nd comment)
2. Every web application, if distributed or not, does have a runtime. In the J2EE world this is the J2EE container. I think implementing security would be a lot easier if all decisions could be delegated to the container. J2EE applications should be agonstic of what the authentication and authorization provider is. Ideally SAML based authentication and authorization is a contract between containers.
3. Whatever comes as a security solution or proposal should not be implemented straight away but integrated to teh J2EE platform in a sensible manner. if Microsoft is interested they will do the same on their side.
Its not SAML vs. JAAS or SAML with JAAS. Its security in a distributed and loosely coupled environment and how it can be made working for everybody to write secure applications.
It's the fragmented solution that just adds to the mess of what's out there. There needs to be a soup-to-nuts solution that everyone can use, no matter what the need is. My discussion was a quick overview only. A SAML server is a very complicated application surely. In fact, I've been sending proposals to JBoss looking to lead their Security Module development. SUN has already started this (proprietary) and they have announced an open-source solution. I would like to see someone like JBoss provide an open source solution with their application server download.
WLS 9.0 has fairly extensive support for SAML 1.1 out-of-the-box. The support provides true single sign-on between multiple Web applications provided they all use SAML. WLS 9.0 can act as a SAML destination, source, or both. See my BLOG posting on SAML at http://dev2dev.bea.com/blog/neilsmithline/
for a quick overview.
David as I tend to agree in theory that your point about SAML being a great idea as it is loose coupled the reality of the situation is that a variety of vendors (SUN, RSA, Ping, etc...) have developed their own proprietary systems that require a lot of synchronization of system related data for the interoperability to work.
For instance if you have every implemented a SAML solution you will notice that the server configurations are assigned to a specific key which is part of the artifact in most cases. This key indicates what server to retrieve an assertion from with a given artifact. While this doesn't seem to be that big of an issue it looks like the way each vendor is implementing this key is kind of a bit off from the next. While the SAML request /response works the authorization of the given artifact with the server requesting the assertion may not work in all cases.
Another issue with the SAML protocol is that they rely on a one use token. This is a very interesting issue when you factor in browser behavior with spyware etc... Some users with spyware will never get in because the spyware software will consume the artifact while the actual customer response will not be able to use the artifact (second post).
So in theory there is a great concept within SAML, in practice it is still not really that robust right now. One other protocol that looks promising is the XACML spec that is being developed. Used in conjuction with SAML in theory should be a pretty good solution given that some of the SAML issues get worked out.
This is a most difficult problem because different businesses have their own thoughts and think they are truly in charge. The way to do this is to solve the pure technical problem and provide a model and show that it works. That's why this article was more to get other interest sparked. I didn't have the final solution. My solution may be flawed, but I hoped people would read it and interest would spark beyond the "cube" so to speak. This needs to be a business community solution. Thanks for your comments.
ID-FF specification are built on top of SAML. ID-FF 1.2 and Shibboleth would be back to SAML as SAML 2.0. SourceID Project
provides open source toolkits for ID-FF 1.2 and SAML1.1, with implementation of SSO profile.
Works for me!
Other links to existing open source Java software that implements SAML 1.1:http://www.opensaml.orghttp://shibboleth.internet2.edu
The latter is a complete implementation of a SAML 1.x authority for authentication and attribute exchange in Java.
Seems like a little googling could have saved the author some time. There's no need to ask for people to write this code, it already exists.
Also, the proper link to the 2.0 specification is http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip
I went through the article and I am a little confused on the token exchange. Let's say there is a identity provider(SAML service) and multiple service providers. I understand they can exchange information using SAML artifacts.
Here is my questions. Lets say a user Joe logs onto SP1 (first service provider) and then he gets redirected to IP (identity provider). The user is authenticated and SAML response sent to SP1. Now if the user goes to SP2, then I think he can be redirected to IP. How does IP know that it is the same Joe? In other words, when requesting for a SAML assertion, how does the SP provide the token or userid to IP? I think the browser has to pass some information to the IP server to let it know that it is requesting assertion for Joe. Without cookies, how is it possible to do that? I heard that SAML eliminates the need for cookies. Can you answer my questions?
Normally a user would enter one site most of the time (not always) and the SAML server would provide the token once and each secondary site would be reached using this token in the URL and the SAML server would be checking hostnames to be sure that the token (user) is coming from an approved site. The token is temporary, but each request to the SAML from any site would be either 1.) a request for authentication in which user and password info would be given or 2.) a request for authentication in which this token is provided along with a hostname. The tokens are created by the SAML server and are temporary. The token along with the hostname provide valuable information on who the user is, what he can do, and what machines he's allowed to do this on. All of this is managed within the SAML server. Naturally the SAML server would require a heavy administrative layer.
Also the token is generated by the SAML server and is time sensitive. The links to secondary sites on any pages would be dynamic. The token would be obtained and the links updated for specific users. Yes, there is potential for sniffing urls, but the hacker would have to use the URL he found in the TCP/IP stream and he would need to use it immediately because of the token timeout. Cookies do not have to be used. If the hacker does not have a valid token for the appropriate situation, he will be requested to provide user and password as in any other application. I guess I would compare a temporary URL string request to someone else using your computer and there's a permanent cookie that allows this other user to get into some application without proper authority.
Another good security feature implementation might be that a single site is required to redirect to the secondary site with the token. The hostname is determined not by URL. The secondary site asks, "is this hostname xxx.xxx.com?" ...if no, user must login at xxx.xxx.com first and then select a link with a SAML server generated token on it's secondary site link.
Let's all vote to stop using cookies.
Really what is going on in the token case is that the application server of sp2 is contacting the IP based on a location configuration within the artifact itself.
The artifact within the token case does not actually have any user information, this information is stored within the assertion that is located at the IP.
So here are a couple scenarios that can work:
1. SP1 registers the assertion to IP and sends the artifact over to SP2. SP2 retrieves the assertion from IP based on the artifact.
2. SP1 creates the assertion and sends the artifact to SP2, SP2 requests the assertion from SP1 based on the artifact. The assertion will have the identity
3. Look at the way the Federated SAML works with the LDAP sync'ing for the IDs.
The text below is from an email reply to a friend. He (Ryan Hoegg) stated that one app or many all want to know if they can trust the user or credentials that are given on application entry. So, I pasted the email here and doctored a few words.
I thought about this some more and yes, I agree the question for all is "how can I trust this
person?". So, in providing a resolution to this:
- SAML server generates an encrypted token that may mean something, may not.
A JBoss service would do "more" than just SAML ...it would generate keys or tokens
etc. for security purposes. Yes, the SAML requests and responses will use
- If multiple applications use the same identity, the token applies to all
- I would only issue the token from a central application
- users trying to just call a spoke application would use JAAS
authentication but still ask SAML for the token based on the "short" path to
security ...basically the user/password thing (no real mousetraps yet)
- the token would time-sensitive and each application would get the hostname
itself. When the SAML request goes in (assuming a token is given) ... two
things are used to answer "can I trust this person?" ...
1. a time sensitive token for this universe (my term lol, bigger than a
realm) of work. and ...
2. the SAML rules will stipulate if e.g. app2 will accept requests from
IP or hostname X only and the token is registered with the SAML service.
For SSO it makes sense to port everyone from a particular hub site. This
would mean that only requests from the hub can be sent "initially" to spoke
sites. After the SAML request is accepted, the user's IP or hostname could
be registered with the SAML service and now all communication must be
between user(A) and spoke site(Z). It would be like once the hub and spoke
are in agreement with this identity, the two communicating IP's would now be
different (but still remain time-sensitive).
I still see all the role and realm and (maybe universe) needs, but I think
JAAS will do all that now. As far as multiple apps and multiple domains,
SAML could give JAAS a nudge and pass along new or different users,
identities, roles, realms, universes, etc. It would be a transference of
security data once trusted.
David aka. piratepete on irc.freenode.net #jboss, #struts, #javapro
The text below is from an email reply to a friend.
Hi there! :)
... If multiple applications use the same identity, the token applies to all apps- I would only issue the token from a central application
... For SSO it makes sense to port everyone from a particular hub site. This would mean that only requests from the hub can be sent "initially" to spokesites.
... As far as multiple apps and multiple domains, SAML could give JAAS a nudge and pass along new or different users, identities, roles, realms, universes, etc.
David aka. piratepete on irc.freenode.net #jboss, #struts, #javapro
Hey that looks a lot like kerberos!
Almost anything you read about SAML (especially at OASIS) is going to talk about federation
. Using federated identities means that you don't have to set up a "hub/spoke" type hierarchy. Each organization or group becomes responsible for its own little piece of the identity universe.
I found this demo
very helpful in understanding SAML's purpose as well as federated identities. I think the Shibboleth
project is a big step in the right direction, and will probably try it out this month.
My company wanted to implement SSO for interanet web application. I had went through GSS-API using kerberos API. But the security team told that for kerberos authentication firewall port needs to be opened . They suggested for SAML. I went through SAML specification. It specifies the message flow but . It didn't specify the authentication technical details.Then i searched for SAML implementation toolkits and found in sourceid. But they also have something called Federated Identity . Now I am confused what to use. If possible kindly provide the details as a difference between SAML , Federated identity and JAAS using kerberos.