I have read some articles about SAML and found it complex. If I got what I read then to implement SAML you need some assertion authority (AA) server accessible by all servers in your domain. This AA server provides to all servers information about current rights and permission of some user(object) in your domain. This information called assertion. If some server has authenticated some user it should notice AA about the fact of authentication. From my point of view, it should add digital signature to the message because other way AA could not trust to this information. Also I can redirect messages from one server in the domain to another. Before then redirect request server should check security assertion of the current user and if assertion is valid then add reference to security assertion to the message and send to another server.
When some server in the domain requires information about the user initiated the request he can access the AA in order to get information about user rights and permissions. If user has been already authenticated by some server in your domain then other server should take for granted that user is part of the domain.
Everything is looking fine but it does not solve the following problems
1. If some malefactor sent forged request to some server in the domain using ID of the already authenticated user we have no chances to verify a user identity. Definitely we have the assertion that this user was authenticated but how can we verify that this particular message came from the user but not from somebody else. Assertion itself does not help me to do it.
2. Case when I redirect request from one server to another is also confusing me. What is a redirection when we speak about WS ? How can I change original user message if it was signed by digital signature in order to add some assertion reference to it. If I want to create a new message and send it again then I don't need any assertion reference. I just create a new message, sign it by my digital signature and send it to the destination server.
3. Assume that some user is sending successive requests to different servers in the domain. I am not sure that there is a way to attach automatically some security assertion to its message - everything should be coded by a developer. Even if we can get from authentication server some assertion reference and then attach it to the message, server could not relay on it because message with assertion could came from anywhere and there is no warranty that the user is the person it claims it is.
But probably somebody tried SAML in production and can provide some practical recomendation that can clear these obstacles?
1. Along with assertion AA can provide sender a secret key (all under cover of HTTPS). Assertion can also contain same key in ecrypted form, encrypted using receiver's public key and stored in SubjectConfirmation element. Then receiver can decrypt the key from SubjectConfirmation and verify that sender have signed the message with it. Nobody else would know the key.
2. What is "WS" and "assertion reference"? If you mean web service1 calling web service 2 on behalf of caller, then either A) WS2 verifies that caller is WS1, and trusts WS1 with caller verification, or B) WS1 obtains assertion for WS2 on behalf of caller from AA, and WS2 processes incoming messages same way as WS1.
3. See 1
1. Along with assertion AA can provide sender a secret key
Did you mean some symmetric key or just some propritery reference to
current user session?
>>(all under cover of HTTPS).
Probably XML Security model is more usefull. It should work faster because
it encrypt only part of the message and In case of HTTPS the public key
is sent just once SSL connection is starting. SSL server does not make a
secret from own public key and send it to
the first comer. Then we could still require that AA knows
public keys of all servers in the domain. Otherwise we need to check
identity of server when it access the AA ant tries to establish
SSL connnection. Please note that
we don't have cookies that keep user session between some server in domaim
and AA. We can have only stateless access from client to AA and then should provide authentication whenever we need some information from AA.
>>Assertion can also contain same key in ecrypted form,
>>encrypted using receiver's public key and stored in
>>Then receiver can decrypt the key from SubjectConfirmation
>>and verify that
>>sender have signed the message with it.
>>Nobody else would know the key.
What is the value of key. This key is a session ID of the user ?
Do you mean that AA is in role of client cookie? When we authenticate a
user we store information about it in some global storage, available
to all servers in the domain.
Probably it would be useful if your read WS-Trust interop scenarios (http://tinyurl.com/uf0r
) before further discussions.
Sorry, I find it hard to understand sentenses like "We can have only stateless access from client to AA and then should provide authentication whenever we need some information from AA".
I got the idea.
Full cycle looks for me:
(R-client, S-server, IP-authentication authority, Sx,Sz-secrect keys)
3.2a R connects IP using HTTPS
3.2b R sends userid/pwd to IP
3.3c IP sends Sx for R (not encrypted) and
"Sx for S" (encrypted by S public key and signed by IP).
4.2a R connects S by HTTP
4.2b R send "Sx for S" (encrypted by S public key and signed by IP) to S
message is signed by Sx to show that R knows Sx
4.2c S send Sz encrypted by Sx. Message is signed by Sx and shows this
way that S knows Sx
4.2d R ans S use Sz to continue the secure conversation.
Does it have any practical implementation ?
Can I using some existent library establish connection
between R and S ? Can some existent tool perform
3.2a-4.2c steps for me or I need to perform these steps my self?
As well it seems that these are pre-assumptions
- R can establish HTTPS connection to IP.
- IP knows S public key.
- R and S know IP public key.
Unfortunately there is nothing out there today that provides the working framework for this scenario, but major vendors are working on providing it. Probably you will have to implement something like this yourself, and throw the code away in future.
Today not only J2EE containers don't support this protocol, but implementing it yourself requires hooks that are non-existing.
FYI Microsoft is going to ship WSE2.0 soon that will let you implement such protocol with minimal amount of code.
About knowing public keys of services and IP - for dynamic discovery you could use XKMS or UDDI.
This is all extremely painful to implement alone. Maybe some open-source project would make sense if there are enough pioneers around :)
We analyzed this scenario and found it as very helpful. SAML is good to make a Single Login entry point in our domain and also enhance security level. Security is enhanced because of the keys are regenerated on the regular base. At least in this scenario client should repeat handshaking after 12 hours.
Right know we are going to use the AXIS for Java that provides the way to encrypt/decrypt the message on the fly and add signatures. But we will carefully
look at the current and new implementations of SAML to find the security functionality we can use.
So thank you a lot for your consultation. Not things look more clear.
Very interesting conversation. I am facing a similar challenge. I need to device a Single Sign On solution for our product. Concept of federated identity seems very appalling special when it could be based on standard solution like SAML and WS-Security. The scenario that you are discussing is very helpful. I am very interesting to hear how Stas manage with his attempt. Perhaps now there is a framework that allows implementation of the scenario mentioned above? Java Web Services Developer Pack 1.5? Appreciate your help!