July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-368) Add optional Supplier<Provider[]> to realm implementations

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-368?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-368: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > Add optional Supplier<Provider[]> to realm implementations > ---------------------------------------------------------- > > Key: ELY-368 > URL: https://issues.jboss.org/browse/ELY-368 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: David Lloyd > Fix For: 1.1.0.Beta8 > > > Realms use key factories, certificate factories, password factories, etc. Most of the time they just use the default installed providers. Enhance the realms to accept an optional {{Supplier<Provider[]>}} which will be used to load these kinds of things. The default supplier should be {{Security::getProviders()}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-376) Password policies

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-376?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-376: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > Password policies > ----------------- > > Key: ELY-376 > URL: https://issues.jboss.org/browse/ELY-376 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI, Passwords, Realms > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.Beta8 > > > Probably needs a design discussion first but we need to review where password policies fit in to the overall solution. > We may say that policy handling is really the responsibility of the actual realm implementation, after all items such as history are going to be very realm specific. > However there may also be a case in the generic sense that where a modifiable realm is in use a policy is desired to cover the complexity of any passwords set on that realm. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-355) HTTP Authentication Mechanism Testing

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-355?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-355: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > HTTP Authentication Mechanism Testing > ------------------------------------- > > Key: ELY-355 > URL: https://issues.jboss.org/browse/ELY-355 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta8 > > > We don't want to create a full HTTP server but we should have a sufficient wrapper to test the HTTP authentication framework and test out specific mechanims. > This will leave the Elytron Web project to smoke test integration and not focus on testing the actual mechanisms. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-344) Review how clients use ModifiableRealmIdentity / ModifiableRealm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-344?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-344: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > Review how clients use ModifiableRealmIdentity / ModifiableRealm > ---------------------------------------------------------------- > > Key: ELY-344 > URL: https://issues.jboss.org/browse/ELY-344 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta8 > > > This may be something we address in the subsystem but just raising here so we don't forget. > Once we have a working set up with a realm which can be modified it seems unreasonable to expect the administrator to know exactly which credential types and names to use. > This may need to be a few milestones away once we have the bulk integrated so the relationships are clear. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-341) PEM file format support

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-341?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-341: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > PEM file format support > ----------------------- > > Key: ELY-341 > URL: https://issues.jboss.org/browse/ELY-341 > Project: WildFly Elytron > Issue Type: Enhancement > Components: KeyStores > Reporter: David Lloyd > Assignee: Pedro Igor > Fix For: 1.1.0.Beta8 > > > We should add support for PEM formats for formats including (but not limited to): > * X.509 Certificate > * CSRs > * CRLs > * RSA and DSA Public and Private Keys > * PKCS8 format Private Keys > * DH parameters > * ECDSA Public Key > * EC Private Key > * EC Parameters > This API could be consumed by various utilities or by custom credential storage implementations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-303) Verify compatibility with RFC7617 "The 'Basic' HTTP Authentication Scheme"

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-303?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-303: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > Verify compatibility with RFC7617 "The 'Basic' HTTP Authentication Scheme" > -------------------------------------------------------------------------- > > Key: ELY-303 > URL: https://issues.jboss.org/browse/ELY-303 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta8 > > > This RFC has now reached the stage of being a proposed standard. > https://www.rfc-editor.org/info/rfc7617 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-444) AuthorizationIdentity and PermissionMapper

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-444: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > AuthorizationIdentity and PermissionMapper > ------------------------------------------ > > Key: ELY-444 > URL: https://issues.jboss.org/browse/ELY-444 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, Realms > Reporter: David Lloyd > Fix For: 1.1.0.Beta8 > > > When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm. But now as the API has evolved it is clear that the permission mapper will need access to more information. The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper. > In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things. Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-443) Update KeyStore backed security realm to iterate it's entries to attempt to find a matching alias for the evidence.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-443?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-443: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > Update KeyStore backed security realm to iterate it's entries to attempt to find a matching alias for the evidence. > ------------------------------------------------------------------------------------------------------------------- > > Key: ELY-443 > URL: https://issues.jboss.org/browse/ELY-443 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta8 > > > Ideally an EvidenceDecoder would have been used up front but as this is technically possible to implement we should do so. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-433: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta8 > > > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-439) Client Cert authentication using certificate passed from a proxy

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-439?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-439: --------------------------------- Fix Version/s: 1.1.0.Beta8 (was: 1.1.0.Beta7) > Client Cert authentication using certificate passed from a proxy > ---------------------------------------------------------------- > > Key: ELY-439 > URL: https://issues.jboss.org/browse/ELY-439 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta8 > > > Undertow contains a feature where by the Proxy server can handle SSL and pass the certificate chain to Undertow - this is then used for the actual client cert authentication. > We need to cover this type of scenario within our generic HTTP authentication framework. > We could further wrap the SSLSession in a similar way Undertow does - or we could make the chain availbale as a fall back. > Related to this we also need to work on the different attachment contexts, that may affect how we consider SSLSession attachments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2016