On 04/15/2014 06:05 PM, Nordgren, Bryce L -FS wrote:
Variant (A) - IdP + PKINIT:
A1) User authenticates to his SAML/OpenID provider (external domain)
A2) User locally generates CSR
A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to
the IdP
A4) IdP returns short-lived certificate
> > Variant (A) - IdP + PKINIT:
> > A1) User authenticates to his SAML/OpenID provider (external domain)
> > A2) User locally generates CSR
> > A3) User contacts IdP (gssapi/saml ; gssapi/openid) and sends CSR to
> > the IdP
> > A4) IdP returns short-lived certificate (validity period matches
> > p
On Mon, 2014-04-14 at 12:23 +0200, Petr Spacek wrote:
> On 13.4.2014 15:21, Dmitri Pal wrote:
> >>> There is where I see a leap of faith. SAML -> SSH. It is not possible.
> >>> And I am not sure OpenSSH would be interested to support it. They had
> >>> hard time supporting Certs.
> >> No SAML->SSH.
On 13.4.2014 15:21, Dmitri Pal wrote:
There is where I see a leap of faith. SAML -> SSH. It is not possible.
And I am not sure OpenSSH would be interested to support it. They had
hard time supporting Certs.
No SAML->SSH. Even if it were possible, it would involve configuring every
host in the do
On 04/11/2014 08:47 PM, Nordgren, Bryce L -FS wrote:
There is a groups pf people that belong to different organizations, for
example universities that launch a project together. They have the identities
in their own home organization (domains). There is a "hosting" organization
that some of the m
> There is a groups pf people that belong to different organizations, for
> example universities that launch a project together. They have the identities
> in their own home organization (domains). There is a "hosting" organization
> that some of the members of the group might belong to. Jointly a
On Fri, 2014-04-11 at 17:58 -0400, Dmitri Pal wrote:
> > C] If I am trying to ssh into one of our collaboration resources
> when I'm visiting a collaborator, I'm forced to use my SAML
> credentials because I can't reach AD. Because we will not be
> synchronizing all users against our SAML IdPs, my
On 04/11/2014 04:22 PM, Nordgren, Bryce L -FS wrote:
I guess we just do not see this scenario in practice yet.
What I've found in the last decade is that scientists and CIO types cannot talk
for lack of a common language. CIO types believe in closed systems over which
they have complete contro
> I guess we just do not see this scenario in practice yet.
What I've found in the last decade is that scientists and CIO types cannot talk
for lack of a common language. CIO types believe in closed systems over which
they have complete control. Scientists are funded to work with others from
o
On 04/10/2014 05:40 PM, Nordgren, Bryce L -FS wrote:
Close. The problem is to expose kerberized services in the local realm to
users holding foreign credentials, supporting SSO wherever possible. This
includes file sharing via NFS, kerberized web apps, ssh logins, and anything
else the local rea
> > Close. The problem is to expose kerberized services in the local realm to
> users holding foreign credentials, supporting SSO wherever possible. This
> includes file sharing via NFS, kerberized web apps, ssh logins, and anything
> else the local realm has to offer. SSSD can handle ssh logins (i
On 04/08/2014 12:50 PM, Nordgren, Bryce L -FS wrote:
Sorry for the delayed reply. This is "other duties as assigned" and the day job
got in the way. :) However, the computer is busy running fits to data for the next day or
so. My electronic master is thus distracted.
Wow!
First of all thanks
Sorry for the delayed reply. This is "other duties as assigned" and the day job
got in the way. :) However, the computer is busy running fits to data for the
next day or so. My electronic master is thus distracted.
> >> Wow!
> >> First of all thanks for a nice pictures and sharing your ideas.
>
On 04/08/2014 09:34 AM, Alexander Bokovoy wrote:
On Sun, 30 Mar 2014, Dmitri Pal wrote:
On 03/30/2014 03:14 PM, Nordgren, Bryce L -FS wrote:
I think it does not really differ from what I described, conceptually.
It is, however, requiring much more work than what I described.
FreeIPA has flat L
On Sun, 30 Mar 2014, Dmitri Pal wrote:
On 03/30/2014 03:14 PM, Nordgren, Bryce L -FS wrote:
I think it does not really differ from what I described, conceptually.
It is, however, requiring much more work than what I described.
FreeIPA has flat LDAP DIT. Adding support for separate OUs is in its
On 03/30/2014 03:14 PM, Nordgren, Bryce L -FS wrote:
I think it does not really differ from what I described, conceptually.
It is, however, requiring much more work than what I described.
FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself a non-
trivial task.
Ah. Well since
> I think it does not really differ from what I described, conceptually.
> It is, however, requiring much more work than what I described.
>
> FreeIPA has flat LDAP DIT. Adding support for separate OUs is in itself a non-
> trivial task.
Ah. Well since that's the case, separate OUs are gone. (You
On Sun, 30 Mar 2014, Nordgren, Bryce L -FS wrote:
Hey guys,
Back again. Thanks for your responses so far.
OTP is interesting, but requires that an account be created in the
local domain, which is kind of opposed to the notion of federated
identities.
Ipsilon is also interesting, from its descr
Hey guys,
Back again. Thanks for your responses so far.
OTP is interesting, but requires that an account be created in the local
domain, which is kind of opposed to the notion of federated identities.
Ipsilon is also interesting, from its description as a gateway to non-Kerberos
identitiy prov
On 03/25/2014 03:12 AM, Alexander Bokovoy wrote:
On Tue, 25 Mar 2014, Nordgren, Bryce L -FS wrote:
Collaboration can be in different ways. It all depends on the use
case. It can be OpenID, SAML, Kerberos, etc. There are different
technologies and they suit better different use cases.
Can yo
On Tue, 25 Mar 2014, Nordgren, Bryce L -FS wrote:
Collaboration can be in different ways. It all depends on the use case. It can
be OpenID, SAML, Kerberos, etc. There are different technologies and they suit
better different use cases.
Can you please share under what circumstances such "in
>Collaboration can be in different ways. It all depends on the use case. It can
>be OpenID, SAML, Kerberos, etc. There are different technologies and they suit
>better different use cases.
>Can you please share under what circumstances such "inversion" would actually
>be needed?
Console login
22 matches
Mail list logo