To achieve this you must use the PicketLink STS. Take a look at this article https://community.jboss.org/wiki/SAMLEJBIntegrationWithPicketLinkSTS.
The article is using JBoss AS 5, but I think it can help you with AS 7, too.
Thank you Pedro, this looks like a weekend job!
A comment though. Ive found picketlink documentation difficult to follow and often out of date.
It would be really good to see an improvement in this area. I saw a post saying 'what does picketlink do' and completely understand why someone would ask that.
Michael, at this time we have not finished our AS7 integration testing for PicketLink. We are making progress. Once we have done our testing, we are going to provide new documentation specific to AS71.
PicketLink is a large project that means many things to *many* people. It is difficult for us to maintain people's expectations.
Thanks for coming back to me. The source of the frustration above comes from spending a lot of time trawling for insights/instructions on picketlink, both official and otherwise. I've been looking at this for both sso and ACL's. I gave up on ACL's eventually because I simply couldn't find enough information to get started. I've spent a lot of time on sso already and I question the clarity of the documentation and if there is more that can be done to make the projects you have more accessible to 'end users'.
For example, here's my requirement. On JBoss 7 I wan't to be able to deploy several wars and ejb projects in the same ear file. The business beans are to be shared and can be accessed by all wars and a single sign on enables access on a single security realm to all war and ejb resources. (I'm familiar with jee in relation to dependencies so that can be taken for granted)
What I would expect is a simple sequence of steps.
a) a summary of what the product does in terms of sso, what the different authentication mechanisms relate to and when they are used.
b) exact steps to configure picket link module for jboss 7 (with alternatives)
c) exact steps to configure each war for participation in authentication for jboss 7 both outside and inside of an ear (jboss-deployment-structure.xml is ignored in sub-projects on jboss 7) (how and why it works)
d) configure each war/ear for authenticating with the ejbContext for jboss 7 and activating both web and ejbContexts at a single login (how, and why it works)
Some of the above is covered in cheat sheets but some aren't which leaves me not really understanding how it works.
Currently I have (by default) the ability to invoke business logic from any of the web applications in my archive but have to login to each . When I add picketlink I can get shared authentication but I can't get the ejbContext so my web applications don't work. I've disabled picket link currently but within the next couple of weeks I'm either going to have to solve this problem or provide my own hacks and get by without sso.
Rant over, thanks for you time!
I must totally agree with Mike. I read through the documentation, and wiki and I still do not get the idea how to configure scenarios Mike mentioned. Soon, I'm about to have something very similar. I would like to have a SSO with my web app. and EJBs. What confuses me most now is the usage of various login modules. My ideal scenario would be like this:
1) A client acesses my web app for the first time. The app. is secured by a security domain configured.
2) A login form appears and the client must log in. The credentials are verified through PicketLinkIDM and SAMLv2 token is issues by PicketLinkSTS.
3) The web app. now validates the token with STS and returns a welcome page.
4) The client clicks on some "action" button which invokes a session EJB. There is a method with @RolesAllowed annotation. The EJB container confirms the token and loads the roles from PicketLinkIDM (the same as before).
How should I configure my security domains and login modules to work like this?
I have an example application that shows some of the features you are looking for.
1) An EAR project configured with a WAR and EJB modules and running in JBoss AS 7.1.1.Final.
2) The WAR is configured as a Service Provider;
3) The EJB is configured with a security-domain that validates a SAML Assertion using the PicketLink STS;
4) When an user logs in the Service Provider, his SAML Assertion (returned by the IDP) is used to call the EJB;
I was thinking in writing an article to describe in more details how things work. Is this example enough for you ?
I have attached a compressed file with the example application. Please read a file named README.txt and follow the instructions.
Both STS and IDP applications are shipped. Please use them to run the example, as described in the README.txt.
Make sure you have a running JBoss AS 7.1.1.Final installation. Read this article and follow the instructions to correctly configure the PicketLink module with this AS version: https://community.jboss.org/wiki/HowToConfigurePicketLink202WithJBossAS711.
As I told you before, the STS configuration is all described here https://community.jboss.org/wiki/SAMLEJBIntegrationWithPicketLinkSTS.
Thanks for this, I'm sure your help is genuine and it's appreciated, but after another 3 hours I can't get this working (there are basic errors).
To whom ever is running this project I have the following message. Please, please get your instructions sorted out properly! I have seen instructions which include jars that no longer exist. The downloads for picketlink now only refer to 2.0.3 for jboss 7.1.* releases where notes on exact configuration actually talk about 2.0.2 only! BTW, I've downloaded 3 versions JBoss to try to get this working so far and the latest still needs patching!
We do have day jobs which are fairly involved and we simply don't have time to waste hour upon hour following misleading information.
My apologies for being negative but I'm tired of going round and round in circles, and this had raised some questions in my mind about JBoss itself if it affiliates itself with communtiy projects that seem to be so immature and I won't be pursuing picketlink further.
Michael, you want something for free. I am not forcing you to use PicketLink. It is your choice.
After working for 3 hours, you give up. Imagine the number of hours we have worked to give this software for free. After that, you complain that it is immature.
I make the statement that "Picketlink is immature for immature/ungrateful people".
We have a day job too. We have many priorities. Inspite of that, we try hard to help the community. It is a mutual respectful two way street.
You are free to use anything else.
Your right of course about the content and tone of my email and you and your team have my apologies. This actually was the latest 3 hours after weeks of downloads, reading and researching and actually the point at which I realised it was dangerous to continue.
The only thing I would say is software, free or not (free is not my major concern, I just don't see a lot of other alternatives) becomes heavily relied upon very quickly and though it's not as much fun as writing software, documenting it, along with a rigid release process is just as important for those who use it. This is what I poorly commented on and meant by 'immature', a process which leaves people struggling. Actually I'm sure your software is very good!
Picketlink is one of those elements that when working and integrated would be fantastic but also a major risk so there lies my concern.
That said I admire anybody that dedicates their own time to develop software and so again thank you for your efforts (and taking it on the chin from bad tempered losers :-)) and good luck in the future.
Michael, my last post was made before I took Nyquil.
For any IDM project to stabilize to do everything on the planet, it takes a decade.
Given PicketLink's timeline, it does quite well what it intends to do. But everything changes as you know. JBoss AS 5/6 have a different architecture than AS7 and Tomcat 5/6 have different things compared to Tomcat 7. So if PicketLink has to satisfy all these servers, it has to endure a lot of customization and testing. Now if we release things once every year to cater to all of these servers, it does not match our user's expectations.
So we try to have frequent releases to give the latest and greatest to our users. The hope is that users catch our errors sooner. The other challenge is the documentation. We have a fair number of how-to articles that can go to out-of-date status with frequent releases. We have to draw a line.
PL started to provide SSO capabilities. Then we started getting demands for EJB, WS integration which is very server specific. Now, we are doing as much as possible with QA.
This is an open source project. We value community interaction. Users are free to provide patches and have frequent outbursts (like you did). But we are going to shoot back if you are being unfair.
What we request from users is to tell us where the bugs are and where our documentation is hard/out of date etc. The community should not be just TAKERS. They have to be GIVERS also. That is the spirit of open source.