I'm almost done with porting the quickstarts. Tomorrow I'll push some changes, so
you can review, ok ?
----- Original Message -----
From: "Sande Gilda" <sgilda(a)redhat.com>
To: "Jess Sightler" <jsightle(a)redhat.com>
Cc: "Pedro Igor Silva" <psilva(a)redhat.com>, "jdf-dev"
<jdf-dev(a)lists.jboss.org>
Sent: Monday, February 24, 2014 5:43:54 PM
Subject: Re: [jdf-dev] PicketLink Federation Quickstarts
Sounds like we have no objections so far. :-)
On 02/24/2014 03:08 PM, Jess Sightler wrote:
If I have understood the PL QuickStarts structure properly, then yes,
I like that approach. :)
----- Original Message -----
> From: "Sande Gilda" <sgilda(a)redhat.com>
> To: "Jess Sightler" <jsightle(a)redhat.com>, "Pedro Igor
Silva" <psilva(a)redhat.com>
> Cc: "jdf-dev" <jdf-dev(a)lists.jboss.org>
> Sent: Monday, February 24, 2014 2:18:59 PM
> Subject: Re: [jdf-dev] PicketLink Federation Quickstarts
>
> I never suggested an EAR! I feel so misunderstood! ;-)
>
> Would a pattern similar to the inter-app quickstart work for this? See
>
https://github.com/jboss-developer/jboss-eap-quickstarts/tree/6.3.x-devel...
>
> On 02/24/2014 02:10 PM, Jess Sightler wrote:
>> As a PicketLink user, I don't think that I would want them to be wrapped
>> into an EAR. I agree that it doesn't match a deployment environment, and I
>> am afraid that it would tend to mislead people.
>>
>> Can't the primary readme for these quickstarts simply explain the required
>> order of deployment and dependencies? Then each quickstart can reference
>> the prerequisite setup. This makes the most sense to me from a user's
>> perspective.
>>
>> How complicated are these relationships? I'm assuming that the primary
>> thing is that the IDP needs to be deployed first?
>>
>> ----- Original Message -----
>>> From: "Pedro Igor Silva" <psilva(a)redhat.com>
>>> To: "jdf-dev" <jdf-dev(a)lists.jboss.org>
>>> Sent: Monday, February 24, 2014 12:13:46 PM
>>> Subject: [jdf-dev] PicketLink Federation Quickstarts
>>>
>>> Hi All,
>>>
>>> After discussing with Sande about the best way to port the PicketLink
>>> Federation (SAML SSO) Quickstarts [1] to the PicketLink JDF
>>> Quickstarts
>>> [2], she asked me to open a thread to collect some more suggestions
>>> about the best way of doing it.
>>>
>>> Basically, the 'issue' we have is that our federation
quickstarts
>>> depend
>>> on each other. This is important because users won't get the whole
>>> functionality if they deploy just one of the quickstarts. Those
>>> quickstarts demonstrate SSO, so we need an authentication authority,
>>> which we call IdP (Identity Provider), and its relying parties, which
>>> we
>>> call SP (Service Provider).
>>>
>>> Today we have 5 different IdP applications, and a bunch of SP ones.
>>> Each
>>> SP relies on a specific IdP, so in order to get functionality working
>>> we
>>> need them deployed together.
>>>
>>> Those quickstarts from [1] are not new, users and also customers are
>>> very
>>> used to see them this way(as separated WARs which you deploy and test
>>> our functionality). Sande suggested us to think about having a EAR
>>> with
>>> all related applications, but this goes against PL real world use
>>> cases
>>> and gives a very wrong understanding about PL usage. For us and our
>>> users, the best thing is keep each quickstart as a single WAR.
>>>
>>> So, given all that, I would like to collect some feedback about the
>>> best
>>> way to document those quickstarts in their README files. Can we have
>>> a
>>> section to reference other related quickstarts ?
>>>
>>> Probably with links to other quickstarts so we can tell users what
>>> they
>>> need to do to get the environment properly set ?
>>>
>>> Any other suggestion ?
>>>
>>> [1]
https://github.com/picketlink2/picketlink-quickstarts/tree/master/saml
>>> [2]
https://github.com/jboss-developer/jboss-picketlink-quickstarts
>>>
>>> Best regards.
>>> Pedro Igor
>>> _______________________________________________
>>> jdf-dev mailing list
>>> jdf-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jdf-dev
>>>
>> _______________________________________________
>> jdf-dev mailing list
>> jdf-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jdf-dev
>