Hi,
I am wondering if the solution I was trying to sketch with the spec
https://review.openstack.org/#/c/96867/13; is not easier to implement
and manage then the steps highlated till n.2. Maybe, the spec is not
yet there and should be improved (I will abandon or move to Kilo as
Marek suggest) but
Dear all,
I am interested to the integration of SAML with keystone and I am analysing
the following blueprint and its implementation:
https://blueprints.launchpad.net/keystone/+spec/saml-id
https://review.openstack.org/#/c/71353/
Looking at the code there is something I cannot undertand. In
Hi Dolph,
On 21 Feb 2014, at 03:05, Dolph Mathews dolph.math...@gmail.com wrote:
On Thu, Feb 20, 2014 at 4:18 AM, Marco Fargetta marco.farge...@ct.infn.it
wrote:
Dear all,
I am interested to the integration of SAML with keystone and I am analysing
the following blueprint and its
--
Eng. Marco Fargetta, PhD
Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy
EMail: marco.farge...@ct.infn.it
smime.p7s
Description: S/MIME cryptographic signature
with different keystones and
administrative domains.
Is this possible with the current replication facilities or they should stay
in the same cloud sharing the keystone?
Cheers,
Marco
--
Eng. Marco Fargetta, PhD
Istituto
there).
Chmouel
On Thu, Mar 13, 2014 at 5:25 PM, Marco Fargetta
marco.farge...@ct.infn.itwrote:
Thanks Donagh,
I will take a look to the ontainer-to-container synchronization to
understand if it fits with my scenario.
Cheers,
Marco
On Thu, Mar 13, 2014 at 03:28:03PM +
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Eng. Marco Fargetta, PhD
Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy
EMail: marco.farge...@ct.infn.it
smime.p7s
3. Unscoped tokens should be very short lived: 10 minutes.
Unscoped tokens should be infinitely extensible: If I hand an
unscoped token to keystone, I get one good for another 10 minutes.
Using this time limit horizon should extend all the unscoped token
every x min (with x 10). Is
Hi All,
• Federated Keystone and Horizon
□ Completely open-ended, there isn't much an expectation that we deliver
this in Juno, but it's something we should start thinking about.
□
I have just registered a new blueprint for this point:
On Tue, May 27, 2014 at 07:39:01AM -0500, Dolph Mathews wrote:
On Tue, May 27, 2014 at 6:30 AM, Marco Fargetta
marco.farge...@ct.infn.itwrote:
Hi All,
• Federated Keystone and Horizon
□ Completely open-ended, there isn't much an expectation that we
deliver
mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Eng. Marco Fargetta, PhD
Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy
EMail: marco.farge...@ct.infn.it
:
On Tue, May 27, 2014 at 8:12 AM, Marco Fargetta
marco.farge...@ct.infn.itwrote:
On Tue, May 27, 2014 at 07:39:01AM -0500, Dolph Mathews wrote:
On Tue, May 27, 2014 at 6:30 AM, Marco Fargetta
marco.farge...@ct.infn.itwrote:
Hi All,
• Federated Keystone and Horizon
/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Eng. Marco Fargetta, PhD
Istituto
.
regards
david
On 24/12/2014 10:19, Marco Fargetta wrote:
Hi All,
this bug was already reported and fixed in two steps:
https://bugs.launchpad.net/ossn/+bug/1390124
The first step is in the documentation. There should be also an OSS advice
for previous
version of OpenStack
list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Eng. Marco Fargetta, PhD
Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy
EMail: marco.farge...@ct.infn.it
parameters. A simple table in Keystone will map the IdPs and
protocols into the correct mapping rule to use.
This is not a huge change to make, in fact it should be a rather simple
re-engineering task.
regards
David
On 24/12/2014 17:50, Marco Fargetta wrote:
On 24 Dec 2014, at 17
. Marco Fargetta, PhD
Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy
EMail: marco.farge...@ct.infn.it
smime.p7s
Description: S/MIME cryptographic signature
This is a good workaround to allow the authentication on the IdP but with the
new websso is problematic because
you do not know which mapping to use but you have the Shib-Identity-Provider.
With the new information
the entityIDs are associated with the keystone IdP so it is easy to find the
Hi Akshik,
the metadata error is in your SP, if the error was on testshib you
should not be redirected back after the login. Maybe there is a configuration
problem with shibboleth. Try to restart the service and look at shibboleth logs.
Check also the metadata of testshib are downloaded correctly
+1
I prefer the ascii art in the specs and/or code doumentation.
Figures could be better in other contexts like user and administrator
manuals but they should not go in the code repository in my opinion.
Cheers,
Marco Fargetta
On Mon, May 11, 2015 at 09:11:24PM -0400, Steve Martinelli wrote
On Thu, Apr 21, 2016 at 10:22:46AM -0400, John Dennis wrote:
> On 04/18/2016 12:34 PM, Martin Millnert wrote:
> >(** ECP is a new feature, not supported by all IdP's, that at (second)
> >best requires reconfiguration of core authentication services at each
> >customer, and at worst requires
21 matches
Mail list logo
