[JBoss JIRA] (ELY-57) Transition to enabling mechanisms to be 'managed' in server environment.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-57?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-57:
--------------------------------
Fix Version/s: 1.0.0.Beta1
(was: 1.0.0.Alpha1)
> Transition to enabling mechanisms to be 'managed' in server environment.
> ------------------------------------------------------------------------
>
> Key: ELY-57
> URL: https://issues.jboss.org/browse/ELY-57
> Project: WildFly Elytron
> Issue Type: Task
> Reporter: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> For some mechanisms there is a fair amount of initialisation that needs to be performed each time the mechanism is used, e.g. for GSSAPI we have GSSName instances, GSSCredential instances etc...
> The existing convention for SASL mechanisms is that this initialisation occurs when the mechanism is instantiated which is at the time the relevant SaslServerFactory or SaslClientFactory is called. This convention really fits with the mechanisms being used in a JSE environment but once we move to a managed environment we are not so constrained.
> A few options: -
> - Provide a way a mechanism can cache something it has created so if called again it can re-use it.
> - Provide access to a factory / inject certain resources.
> - Make the mechanism fully managed in the server, when create is called the bulk of initialisation would have already occurred and what is returned handles the bare minimum state related to an authentication attemp (client or server side).
> One additional comment if we do consider something like this, some mechanisms may have items cached that once cached would never change for the lifetime of the process - for others we may have additional timeouts to consider such as Kerberos ticket expiration which may mean we want to regenerate cached resources at certain points.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (ELY-119) XInclude (or just plain inclusion) support for Elytron XML schema and/or parser
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-119?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-119:
---------------------------------
Fix Version/s: 1.0.0.Beta1
> XInclude (or just plain inclusion) support for Elytron XML schema and/or parser
> -------------------------------------------------------------------------------
>
> Key: ELY-119
> URL: https://issues.jboss.org/browse/ELY-119
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI
> Reporter: David Lloyd
> Fix For: 1.0.0.Beta1
>
>
> It could be as simple as interposing a DOMSource in between the file stream and the reader, or creating a wrapper XMLStreamReader which implements the include.
> But I'd prefer a solution that stacks {{org.wildfly.security.auth.XMLLocation}} instances in order to give clean and concise error messages with an "include stack trace" bundled with it. Note that this requires adding a "parent" location field to that class.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months
[JBoss JIRA] (ELY-34) Create a JAAS based security realm.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-34?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse updated ELY-34:
--------------------------------
Fix Version/s: 1.0.0.Beta1
(was: 1.0.0.Alpha1)
> Create a JAAS based security realm.
> -----------------------------------
>
> Key: ELY-34
> URL: https://issues.jboss.org/browse/ELY-34
> Project: WildFly Elytron
> Issue Type: Sub-task
> Components: Realms
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> Legacy integration is always going to be a concern so should verify that we can delegate to JAAS if required.
> _Delegating to JAAS is always going to simplify the password types supported so this is more of an ensure we can integrate with JAAS rather than ensure we can fully integrate with JAAS._
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 6 months